The MPLS WG Archive

[Adrian Farrel <AF@dataconnection.com>]

Lou and Peter,

Thanks for a great job editing this and for getting it out into the public
domain.	

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.  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?
 

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


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.


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.


3.5.1 Label Set
It isn't clear how a sequence of subchannels that form a 
label set are conveyed.  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?


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. 


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


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.


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.


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?


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


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.


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).
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).


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


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.


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?

   
6.2 Procedures
The text listing the errors could do with some cleaning.
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.


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
- 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.  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





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

page 4  for "ends on a LSC" read "ends on an LSC"

page 5  for "traditional and and non-PSC" read "traditional and non-PSC"

page 6  for "come from non-PSC" read "comes from non-PSC"

page 7  for "as specific a LSP Encoding Type" read "as specific an LSP
Encoding Type"

3.2.1.1 for "SDH and SONET define each" read "SDH and SONET each define" 

3.2.1.1 for "directly the distinction" read "the direct distinction"

3.2.1.1 for "take part into the inverse" read "take part in the inverse"

3.2.1.1 for "higher order signal need to be" read "higher order signal needs
to be"

3.2.1.1 for "in the increasing order" read "in increasing order"

3.5     for "there are a sequence" read "there is a sequence"

4.3     for "since the label sets are exchanged" read "if the label sets are
exchanged"

5.1.2   Notify Target Object should be Notify Request Object (twice)

5.2     for "who's" read "whose"

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

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

6.      for "This occurs case when" read "This occurs in the case when"

9.      strike "Non-adjacent bundle messages, and"

10.     rsvp-lsp-tunnel is up to version 7 now.
--
Adrian Farrel  mailto:af@dataconnection.com
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.dataconnection.com/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422