Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)
draft-ietf-mpls-crldp-unnum-10

2002-12-04- from alex
Loa,

  Sorry for the delay.
 
  One of the situations with a loose hop and unnum TLV that the draft
  didn't seem to discuss is when you have a strict ER-Hop with the
  egress unnum interface specified followed by a loose ER-Hop. The
  draft says to just follow "the rules specified in section 4.8.1 of
  [CR-LDP]", which says to select any next-hop towards the next
  abstract node, while the whole purpose of the unnum TLV seems
  to imply choosing a specific egress interface.

  I'm not intending to push on this one hard given the final
  destination of the CR-LDP stuff :), but since I didn't see this
  addressed, I wanted to bring it to your attention, so that you
  probably add some words if you believe this is important.

--
Alex

2002-12-04 - from WG chair & author
Loa,

> let me see if I understand this correctly (Yakov - correct me if I'm
> wrong!)
>
> The strict/loose property of an LSP is a property is a property of the
> the end-2-end connectivity. E.g. you want to set up an LSP from A to G,
> the strict part of this is that you want to go through node B and C,
> but don't care about the rest of the nodes.
>
> When signaling the LSP node A signal to B (no alternative but still a
> loose hop), then B signals to C (no alternative, strict hop), then C
> (with three options [d,e and f] signals to e (loose hop), and finally
> e signals to G (no alternative, whether his philosophical is a strict
> or loose hop would be an interesting debate (somewhen else)).
>
> Now, the links [B to C] and [C to e] could both be unnumbered, but one
> is strict the other loose, and the links [A to B] and [E to G] numbered,
> but one is strict the other loose.
>
> Point is strict/loose relates to the LSP as such and constraints on
> routing and is a network property. unnum/num relates to signaling
> between two nodes and is a link local property, i.e. unnum/num is valid
> both for strict and loose hops.

I think I comment on this before, but just to add to your response...
Numbered vs unnumbered is just a way to identify interfaces/links.
Both provide an unambiguous way to identify a particular link.
Strict vs loose has to do with selecting links (with routing), and
is orthogonal to whether a link is identified by either an IP
addresses (numbered) or  tuples. Thus the
interpretation of strict/loose bit in the ERO is the same irrespective
of whether links are numbered or unnumbered, and therefore the
current specification of this bit is sufficient.

If Alex has an example where loose hops don't make sense with
unnumbered interfaces (but do make sense with numbered interfaces),
or where the current interpretation of the strict/loose bit is
insufficient in the case where the interfaces are unnumbered (but
is sufficient when the interfaces are numbered), then he should
just share it with us.

Yakov.

2002-12-03 - from alex
Almost. Looks like the question I quote below is still open:
> Please add another comment:
>
>> 7. Signalling Unnumbered Links in EROs
>
> says:
> [...]
>>    The L bit is set to indicate a loose hop, and cleared to indicate a
>>    strict hop.
>
> Not sure "loose hop" makes sense in the case of an unnumbered
> interface where we identify a specific link on a specific node.
> In any case, interpretation of this bit needs to be specified.
>
> Alex

2002-10-17 - another iesg comment to WG chairs

don't we mean assigned by the IANA?

  6.1. LSP_TUNNEL_INTERFACE_ID TLV

  The LSP_TUNNEL_INTERFACE ID TLV has Type to be determined by IETF
  consensus and length 8.

similarly for

  UNNUMBERED_INTERFACE_ID

randy

2002-10-17 - another iesg comment to WG chairs

> 7. Signalling Unnumbered Links in EROs

says:
[...]
>    The L bit is set to indicate a loose hop, and cleared to indicate a
>    strict hop.

Not sure "loose hop" makes sense in the case of an unnumbered
interface where we identify a specific link on a specific node.
In any case, interpretation of this bit needs to be specified.

2002-10-17 - revised comment from alex
Please remove bullet 2 from my list below. My bad. I rechecked as I
thought the TLV was defined somewhere, and I found it in draft-ietf-
mpls-generalized-signaling.

2002-10-16 - IESG comment
1. Same problem as with rsvp-unnum: it uses the term "Router ID"
  which is not defined anywhere.

2. The doc talks about "IF_INDEX TLV", which does not exist.
  I believe the same is valid for rsvp-unnum, btw.

3. The draft talks about "Processing the ERO", while "ERO" is
  an RSVP-specific notion, and has no meaning in CR-LDP.

State Changes to New Version Needed (WG/Author)                    from Last Call Issued                                  by jhargest

State Changes to Last Call Issued                                  from New Version Needed (WG/Author)                    by jhargest

2002-06-02 - note to chairs - sob
> acronyms must be expanded in title and abstract
> MUST etc used but not defined (eg. add reference to RFC 2119)
> needs IANA considerations section to assign new subobject

State Changes to New Version Needed (WG/Author)                    from Pre AD Evaluation                                by sob

State Changes to Pre AD Evaluation                                from In WG                                            by sob