The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

> Questions
> =========
> 
> 4.4.1.3 Recorded Label Subobject
>     I can see how this is useful information for NM.  Is the label
>     completely useful without knowing the label space from which the 
>     label comes?  This would be exposed as an interface index or a 
>     magic value for the global label space.  This could easily be added 
>     to the subobject to give...
> 
>        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
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |     Length    |    Flags      |   C-Type      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |       Interface Identifier                                    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |       Contents of Label Object                                |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     with the following text
> 
>       Interface Identifier
> 
>          The interface index that identifies the label space from which
>          this label comes.  A value of zero (0) indicates that the label 
>          comes from the global label space.

The generalized label object will carry a link ID.  So if this is
needed that we can simply use that format.
(see draft-ashwood-generalized-mpls-signaling-00.txt)

> 4.4.2 RRO Applicability
>     The text inherited from the previous draft says that an RRO can
>     be converted to an ERO "with minor changes".  This has now been
>     broken by the addition of the Label subobject.
>     It would be unfortunate (but perhaps necessary?) to require that
>     the RRO is parsed when pinning a session path.  The alternative
>     would appear to be to allow the Label object to be present but
>     ignored in the ERO.

There are two outs here. The head end can refresh the path with the
bit off which will cause a fresh recording without the label
information.

The other out is as you suggest.  I think it's much cleaner for the
node which is formating the ERO to worry about this, so I would oppose
including the label having the ERO processing skip over the subobject.

> 4.5 Processing RRO
>     The text here describes adding the Label Record subobject whenever
>     the SESSION_ATTRIBUTE indicate Label_Recording.  Of course, this 
>     is typically only possible on the reverse path.  Thus the RRO on 
>     he forward path need not include the LR subobject.

If no one objects, I'll limit the Label Record to the RESV message.

> 4.5 Processing RRO
>     Can we allow for nodes that don't support adding Label Record
>     subobjects?  Or is this covered in "SHOULD"?

Yes.

> Editorial
> =========
> 
> 2.6 Step 2. If DF bit not set step a)
>     Would it be clearer (and no less accurate :-) to replace "the value
>     of the parameter" with "M"?

Done.

> 3.2 Expanding <FF flow descriptor list> leads to (optionally) two
>     instances of <FLOWSPEC> for a single <FILTER_SPEC> and <LABEL>.
>     I'm assuming you didn't want this (or is there a cunning use?)
>     and that the correct correlation to adding <FLOWSPEC> to the
>     <FF flow descriptor list> is to remove it from the
>     <FF flow descriptor>.

See archive.

> 4.8.1 Session Attributes - Flags (ditto 4.8.2)
>     Is it wise to re-use the "Merging Permitted" flag for "Label 
>     recording desired"?  won't this cause interop issues with old
>     implementations?

As far as I know nothing in the field is using the "merging permitted"
bit, so I reused the value.

> Typos
> =====

Thanks.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824