Subject: [mpls-tp] Second Last Call Comments on draft-ietf-mpls-tp-gach-gal-02

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Mar 2009 17:38:31 -0000

Hi,

Thanks for addressing most of the points I raised in the first last call.

A couple of acronyms remain un-expanded.

> You need to expand acronyms on first use. (You can't inherit the
> expansions from the Abstract.)
> I see...
>  LSP
>  PW

One significant point remains. I'm sorry if I missed the discussion of this 
point on the mailing list.
I feel it does need to be addressed...

> Section 7 (now 8)
>
>   32752 - 32767 : Experimental
>
> This is far too many experimental code point. Please see RFC 3692
> section 1.1 that suggests that in most cases a *single* experimental
> code point is enough, and that multiple codepoints may be risky.
>
>   Code points in the experimental range MUST be used according to the
>   guidelines of RFC 3692 [14].  Experimental OAM functions MUST be
>   disabled by default.  The channel type value used for a given
>   experimental OAM function MUST be configurable, and care MUST be
>   taken to ensure that different OAM functions that are not
>   interoperable are configured to use different channel type values.
>
> This is precisely the point! The intention is not to allow a situation
> where deployments use multiple different experimental channel types.

There are a few (mainly editorial) points from the new draft...

2.1.  Definition

   In the above figure, the first nibble is set to 0001b to indicate a
   control channel associated with a PW, an LSP or a Section.  The
   Version field is set to 0, as specified in RFC 4385 [6].  Bits 8 to
   14 of the G-ACH are reserved and MUST be set to 0 and ignored on
   reception.

You have left bit 15 dangling

===

2.2.  Allocation of Channel Types

   The Channel Type field indicates the type of message carried on the
   associated control channel e.g.  IPv4 or IPv6 if IP demultiplexing is
   used for messages sent on the associated control channel, or OAM or
   other maintenance function if IP demultiplexing is not used.  For
   associated control channel packets where IP is not used as the
   multiplexer, the Channel Type SHOULD indicate the specific
   maintenance protocol carried in the associated control channel.

I really don't like "SHOULD" here.
Can't you say, "...the Channel Type indicates the specific..."

   Values for the Channel Type field currently used for VCCV are
   specified elsewhere, e.g. in RFC 4446 [7]and RFC 4385[6] .

Odd spacing around references.

===

3.2.  ACH TLV Header

   The ACH TLV Header defines the length of the set of ACH TLVs that
   follow.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Length                 |          Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 3: ACH TLV Header

   The length field specifies the length in octets of the complete set
   of TLVs including TLVs that follow the ACH TLV header.  A length of
   zero indicates that no ACH TLV follow this header.

c/TLVs including TLVs that follow/TLVs that follow/

I think it is important (given the behaviour in many MPLS-related
control plane protocols) to state that there is no padding required for
the set of ACH TLVs.

===

3.3.  ACH TLV Object

   An ACH TLV consists of a 16-bit Type field, followed by a 16-bit
   Length field which specifies the number of octets of the Value field
   which follows the Length field.  This 32-bit word is followed by zero
   or more octets of Value information.  The format and semantics of the
   value information are defined by the TLV Type as recorded in the TLV
   Type registry.  See Section 8 for further details.  Note that the
   Value field of ACH TLVs MAY contain sub-TLV objects.

c/sub-TLV objects/sub-TLVs/

I think it is important (given the behaviour in many MPLS-related
control plane protocols) to state that there is no padding required for
individual TLVs or sub-TLVs.

===

4.2.1.1.  MPLS Label Switched Paths and Segments

   o  The TTL field of the GAL MUST be set to at least 1.  The exact
      value of the TTL is application specific.

You added some nice text in 4.2.1 to get around having to give any clues
in this document. I suggest you defer to it.

   o  The S bit of the GAL MUST be set according to its position in the
      label stack.

True, but see section 4.2 where we are told that for MPLS-TP, the S bit
must always be set.

   o  The setting of the TC field is application specific.

s/TC field/TC field of the GAL/

Ditto the nice text in 4.2.1.

===

4.2.1.2.  MPLS Section

   o  The TTL field of the GAL MUST be set to at least 1.  The exact
      value of the TTL is application specific.

You added some nice text in 4.2.1 to get around having to give any clues
in this document. I suggest you defer to it.

   o  The S bit of the GAL MUST be set according to its position in the
      label stack.  For MPLS Sections, the S bit MUST be set to 1.

   o  The setting of the TC field is application specific.

s/TC field/TC field of the GAL/

Ditto the nice text in 4.2.1.

===

5.  Compatability

   In addition, it MAY increment an error counter and MAY also
   optionally issue a system and/or SNMP notification.

"opitonally" is redundant

===

8.  IANA Considerations

   This document requests that IANA allocates a label value, to the GAL,
   from the pool of reserved labels, and suggests this value to be 13.

It is helpful to IANA if you name the registries that you are refering
to. In this case "Multiprotocol Label Switching Architecture (MPLS)
Label Values".

===

Thanks,
Adrian

---

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 9 Mar 2009 10:47:12 +0100

Hi Adrian,

Thanks for your comments.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 07 March 2009 17:39
> To: [email-masked]
> Subject: [mpls-tp] Second Last Call Comments 
> ondraft-ietf-mpls-tp-gach-gal-02
> 
> Hi,
> 
> > expansions from the Abstract.) I see...
> >  LSP
> >  PW

OK thanks.

> 
> One significant point remains. I'm sorry if I missed the 
> discussion of this point on the mailing list.

I think that this is an exceptional case, because we have a relatively
large range of G-ACh protocols that could be in development at any one
time, and several might be required in order just to bootstrap a node in
an experiment. Ideally, an implementer should be able to run a given
experimental G-ACh protocol during the develoment and standardisation
phase on an experimental channel type without having to sub-type below
that, and then move that protocol wholesale to a standardised code point
when one is allocated for it by IETF action. I think it is fairly easy
to imagine an experiment between 3 or 4 vendors who are testing the
interoperability of a standardised G-ACh protocol but who need a few
experimental protocols to run between their boxes in the initial phases
of MPLS-TP development. 

Given that we have 32k potential channel types, and tens of protocols in
development at any given time, 16 seems a reasonable number of
experimental code points.      

> You have left bit 15 dangling

OK thanks. 

> Can't you say, "...the Channel Type indicates the specific..."

Yes, I agree with you.

> Odd spacing around references.

Thanks. That would be the xml editor's fault :)

> I think it is important (given the behaviour in many 
> MPLS-related control plane protocols) to state that there is 
> no padding required for the set of ACH TLVs.

OK

> I think it is important (given the behaviour in many 
> MPLS-related control plane protocols) to state that there is 
> no padding required for individual TLVs or sub-TLVs.

OK

> You added some nice text in 4.2.1 to get around having to 
> give any clues in this document. I suggest you defer to it.

Yes, although that reference in 4.2.1 really only says that the oTTL at
an LSR must be the iTTL-1, and not what it should be intially set to,
which is the application-specific bit. I propose adding a
cross-reference to 4.2.1 thus:

    o  The TTL field of the GAL MUST be set to at least 1.  The exact
       value of the TTL is application specific. See Section 4.2.1 for
definition and processing rules.

> True, but see section 4.2 where we are told that for MPLS-TP, 
> the S bit must always be set.

However, this draft is not specific to MPLS-TP. I propose just adding a
xref to Section 4.2 here.

> Ditto the nice text in 4.2.1.

OK.

> You added some nice text in 4.2.1 to get around having to 
> give any clues in this document. I suggest you defer to it.

OK, I suggest adding the same text as above.

> Ditto the nice text in 4.2.1.

OK.

> "opitonally" is redundant

Agreed.

> It is helpful to IANA if you name the registries that you are 
> refering to. In this case "Multiprotocol Label Switching 
> Architecture (MPLS) Label Values".

OK.

Thanks

Matthew

> 
> ===
> 
> Thanks,
> Adrian
> 
> 
> 
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>