The MPLS WG Archive

[Lou Berger <lberger@movaz.com>]

Adrian,
         Thank you very much for the detailed comments.

At 02:11 PM 10/23/00, Adrian Farrel wrote:
>Lou and Peter,
>
>Thanks for a great job editing this and for getting it out into the public
>domain.

I'd love to take all the credit but, as is shown by the Author's list, 
there are lots of folks working on the document.

>I have a large block of comments and questions and bunch of minor typos.
>Please feel free to split the comments into separate threads if you like.
>
>Regards,
>Adrian
>
>Questions
>=========
>
>Link Id and Explicit Routing
>I'm not sure how much this should be in Kireeti's bundling draft
>and how much in the Generalized draft.  I have the following
>concern:
>
>- Suppose we use LSR addresses (i.e. not link addresses) in our
>   explicit route and also use label sub-objects.

This should result in an error.  The text says:
    The Label subobject follows a subobject containing the IP address, or
    the interface identifier [MPLS-UNNUM], associated with the link on
    which it is to be used.

I'll make the text more explicit on this point.

>   Suppose further
>   that there are multiple links of different types between a pair
>   of LSRs.  Finally consider that Label_Request is used, not
>   Generalized_Label_Request.
>
>   How does the LSR processing the ERO interpret the label and
>   decide which link to apply it to?
>   I guess you could say that you should avoid the combination of
>   circumstances listed above and use G_L_R to constrain the link
>   type or use the link address not the LSR address.  Does that
>   still work with unnumbered links?

This situation SHOULD result in an error. The next rev will be more explicit.

>Error values etc.
>Can I suggest adding a section at the end as a place holder for new error
>values.
>In the text I have found
>- Routing Problem/Unsupported Encoding
>- Routing Problem/Unsupported Link Protection
>- Routing Problem/Unsupported GPID
>- Routing Problem/Unacceptable Label Value
>- Routing Problem/Label Set

This is *really* stylistic, do you really care?

>3. Generalized Label Request
>Could you make it clearer right at the top of section 3 that
>for RSVP the Generalized_Label_Request is not a new object but a
>new variant of the Label_Request Object, whereas for CR-LDP it is
>a new TLV.

This too seems like a style comment.


>3.3.1 Waveband Switching
>"For compatibility reasons, a new RSVP c-type and CR-
>  LDP type is assigned for the Waveband Label."
>This seems to be the only place in the draft where you
>haven't explicitly suggested values (subject to IANA).
>
>I think you have left gaps for RSVP c-type 3 and CR-LDP
>type 903.

Thanks.


>3.5.1 Label Set
>It isn't clear how a sequence of subchannels that form a
>label set are conveyed.

I agree, the text needs to be cleaned up. Thanks for pointing this out.

>It can't be the case that you
>simply add multiple Subchannels to the Object/TLV since
>the Type is closely associated with each individual
>Subchannel.
>
>We should either define Label_Set as Explicit_Route with
>a sequence of subobjects.  Or we should allow a series
>of Label_Sets in the Path/LABEL_REQUEST.


>In either case, it would be good to put in some motherhood
>about ordering the elements for clear interpretation. For
>example, suppose x<y<z.  Can I define the label set
>{x, x+1, ... , y-1, y+1, ..., z} using three subchannels
>(viz. start x, exclude y, end z) or must I use four?

There's already words on ordering.  This doesn't diminish your earlier point.

>3.5.2 Label_Set Procedures
>I suppose it is implicit, but there is no mention of inserting
>Label_Set for the first time.
>
>
>4. Bidirectional LSPs
>I think it would help to point out that the support for
>bidirectional LSPs added here is restricted to certain levels
>of symmetry
>- the TSpec is the same in both directions
>- the LSRs on the path are the same in both directions
>- the links between LSRs are not necessarily the same in both
>   directions.
>

All but LSRs were already mentioned.  I added LSRs to the list.

>Suggested_Label
>Sorry if I missed this.
>Must Suggested_Label be chosen from within the Label_Set?

It's not a requirement, but use of such a suggestion will guarantee that 
the suggestion will not be used.


>4.2 Bidirectional LSP Procedures
>The choice you have made is consistent (that you may not
>propagate a Path containing Upstream_Label until the local
>switch has been programmed, so that the terminator may start
>sending data as soon as it has processed the Path) but may
>unnecessarily increase the latency of LSP set up (compare
>with the arguments for Suggested_Label).
>If ResvConf were to be requested and used, the individual
>switch programming tasks could be processed in parallel with
>the propagation of the Path message.  The terminator is not
>allowed to start sending data until it receives the ResvConf.
>This is a direct trade-off, but could quite easily reduce
>setup time for individual LSPs.

This is a reasonable representation of the choice that was made.


>4.3 Bidirectional LSP Contention Resolution
>Note that action on receipt of a PathErr is in contradiction
>with RFC2205.  This is, however, the correct function in the
>situation described.
>

if by "contradiction" you mean "different", I agree.

>4.3 Bidirectional LSP Contention Resolution
>The suggested behavior for reducing contention depends on
>adjacent LSRs knowing each other's node IDs.  Does this
>rely on Hello messages, carnal knowledge or what?

from the draft:
    For the purposes of RSVP contention
    resolution, the node ID is the IP address used in the RSVP_HOP
    object.


>5. Notification
>Flag this at the top as being RSVP only.

The draft will soon be split (as mentioned at the last WG meeting) into a 
CR-LDP and RSVP draft, it'll be 100% clear at that point.


>5.1.2 Notify Request Procedures
>We should add a statement about multiple instances of this object.
>The current discussion allows just a single instance.

This is by design.  Others have made the same point, but it wasn't clear 
that this functionality is really required.  Why do you believe this is needed?


>5.2.2 Notify Procedures
>This version of the text does not prohibit the Notify Node from
>being other than the requester (i.e. initiator or terminator).

Again, this is by design.

>We should either impose this for the time being, or note that
>the Notify Node might not support Notify messages (and so will
>not send an Ack).

If you really think it's not obvious, we can state that the node inserting 
the NOTIFY_REQUEST must use an IPv4 Notify Node Address of a node known to 
support the notify message.


>5.2.2 Notify Procedures
>It's not clear to me that the default time of 1ms for combining
>Notifies is relevant.
>

Not having default time values has held up other drafts.  I put in a 
default to avoid this problem in the future.

>5.3 Removing State with PathErr
>Note that the reference to RFC 2205 here is obsoleted by the
>actions required for bidriectional LSPs (see 4.3) and by
>processing that may be utilized for local repair and fast
>re-route.
>In effect, RFC 2205's rules for forwarding PathErr without
>taking action have are already bent.

so noted.


>5.3 Removing State with PathErr
>
>Can we add some text describing the Path state on downstream
>nodes when Path_State_Removed is used.  If I receive PathErr
>w/o P_S_R, am I allowed to remove Path state and send PathErr
>w/ P_S_R?

from the draft:
   If the Path state is
    removed the Path_State_Removed flag SHOULD be set in the outgoing
    PathErr message.  A node which does not remove the associated Path
    state MUST NOT set the Path_State_Removed flag.  A node that receives
    an error with the Path_State_Removed flag set to zero MUST NOT set
    this flag unless it also generates a corresponding PathTear message.


>
>6.2 Procedures
>The text listing the errors could do with some cleaning.

okay, will review.

>The L-bit isn't the only issue here.  The nature of the previous
>sub-object can be strict but imprecise (i.e. a non-unitary
>abstract node .. prefix != 32) or could be an Autonomous System
>number. In CR-LDP, the subobject could be an LSPId.

As previously mentioned, all these cases are invalid and should result in 
an error.  The next rev of the draft will be more explicit.


>Reporting explicit labels.
>draft-ietf-mpls-rsvp-lsp-tunnel-07 has scope in the RRO for
>reporting labels, but this doesn't quite match the ERO extensions
>here.  In particular we need
>- scope for two label objects per hop

A good point!

>- definition of the U bit
>I believe that this should be in a new section 6.3
>
>
>Specifying links in EROs
>I know we discussed this a bit before, but I want to check that
>we're in synch.
>We're allowing the IP address subobject in an explicit route to
>identify an egress link rather than a next hop.  It becomes a
>local matter how such subobjects are handled.
>We are not allowing specification of a link _and_ a next hop. This
>rules out parallel links in a multidrop network.
>We do not have the ability to specify an unnumbered link.

I don't understand why you say this.

>This is
>seen as illogical since the indexes of unnumbered links have only
>local (and possibly extending to the other end of the link) meaning.
>
>
>BNFs
>Label_Set is optional
>

Thanks.




>Trivial typos (haven't I got better things to do?)
>=============
>

Thank you!





>5.2     "Notify Ack" is obsolete, read "Ack"

I couldn't find this.  Can you provide more context.

>5.3     for "receiving such a error" read "receiving such an error"


I couldn't find this.  Can you provide more context.


Thank you again for the detailed comments,
Lou