Re: [mpls] MPLS-RT review of [e-mail]

["Kamran Raza (skraza)" <[e-mail]>]

Hello draft authors,

I was assigned to review this draft as part of MPLS-RT process. I have reviewed the document and think that it needs to address some of the review comments (by MPLS-RT reviewers) before it can be asked for WG poll [ at which point Eric Gray comments regarding falling under WG charter andor RFC vs BCP will also apply ]

Please see my comments along with some protocol accuracy/NITs:

- The draft does not talk about any scalability implications due to additional || LDP sessions. IMO, a section on Scalability is needed.

- IMO, it is not very clear on inter-op with non-supporting implementation --
   I am trying to understand, how would this work if one side is doing multi-instance, other is not.

         Node - A                                                                            Node - B
       +-------------+                                                                      +--------------+
       |   LSR-A:0--|============IF 1==============|---LSR-B1:0   |
       |                 x |                                                                     | x                  |
       |   LSR-A:0--|============IF 2==============|---LSR-B2:0   |
       |                    |                                                                    |                       |
       +-------------+                                                                     +-----------------+

    "A" will try to form 2 sessions with "B" but "B" will try to form one session with "A" ? Only one session will/can come up ?

- If we take out "Node ID" TLV (the need for which was already discussed by other reviewer Lizhong), this doc is not defining any new
  Standard/extension.

- The document keeps talking about label/FEC mapping and does not mention address bindings in most sections.
  Later,  towards the end of the document, there is Section 4 on Address mapping. I'd suggest writing something upfront in the draft rgding Addr bindings;
  or use generic term "binding" (which means both label and address bindings)

- Section 2: "Since the multi-instance procedures use same LDP Indentifer as defined in
   [RFC5036], it makes the node running multiple instances to be
   backward compatible with the node that support the multi-instance LDP
   procedures."

I'd think you meant to say that multi-instance LDP is backward compatible with the node
that does not support multi-instance LDP ? If yes, the para above is not accurate.

- Section 2.1: Any rule for address bindings disjointness ?

 - Section 2.1: The following sentence is confusing,
"The above rules does not apply between multi-instance LDP sessions with different peering LDP nodes."
Can u plz rephrase ?

- Section 2.1.1: Case 1 mandates "Hellos MUST carry LDP Adj Capabilities" but does not elaborate on what/how?
  Although it mandates "MUST" for Hello Adj Capabilities, it uses "SHOULD" for session capabilities
  "The LSP session SHOULD be set-up with capabilities of FEC group …"
  Would this not conflict/violate the earlier stated MUST rule of  ensuring "disjoint FEC types" on fate separated session ?

 - Section 2.1.2: case 2: "Each of IF1 and IF2 would originate two separate Hello
   Messages using the same source IP address"

   Why can't they use different source address ? Why limit ?
   Moreover, when IF1 and IF2 are single-stack IPv4 and IPV6 interfaces, then the statement has bigger problem - the Hello msgs can not have the same source address; they have to  uses the different src address (different AF reasons).

- Section 2.1.2: "Each Hello Adjacncies SHOULD advertise capabilities using rules described in case 1.":
In previous section, it was "MUST" for adj capabilities. Here, it has become SHOULD ?

- Section 3: When receiving same FEC on two peering sessions from same node:
  - elaborate on procedures on rx ? does it withdraw label from both sessions ?
    does it just keeps using from one and discard 2nd one ?
    if first one wins, then it is indeterminstic across different instances of the same instance.
 - Why not define new status code ? why limit to use "LOOP-DETECTED" ?

- Section 3: If the receiver does not understand "Node Id TLV", it won't be able to
   detect the above and hence will keep both in its LIB (across different peers).
   While this may not pose much a problem for labels, it may cause problem for addresses
  (conflicting peer addresses may cause broken forwarding due to incorrect mapping of
   IP nexthop to peer – using peer address mapping)

- Section 3:  Can we rename "Node ID" TLV to "Multi-instance Node Id" TLV?

- Section 4:
  Your document uses "MAY" for address bindings disjointness across || sessions.
  For some capabilities/apps, advertising the full address space will be simple and make sense, for others it will not.
  Should we not make address space segregated as required for a given capability ? e.g. when running in case 4 (2.1.4), we should only advertise v4 addrs on v4 session and
  v6 addrs on v6 session.

Spec Accuracy
===========
- Section 1:  "Although [RFC5036] does not specify that the 4 byte router-id of the
   LDP identifier be routable IP addresses"

 I'd call it 4 octet LSR Id  and not 4 byte router-id.

- Section 1: "Thus there is need to host multiple LSRs by a network node that shares the same label space but
   each with unique router-ids."/
  "Thus there is need to host multiple LSR Ids by a network node that share the same label space"

- Section 2: "unique 4 byte router-id but same label space" / "unique 4 byte LSR Id but same label space"

- Section 2.1.1: "For example Group 1 can contain all transport specific FEC
   types such as IPV4 FEC Element Type and LDP Multi-point (MP) FEC
   types etc.  " /
 "For example Group 1 can contain all transport specific FEC
   types such as Prefix FEC and LDP Multi-point (MP) FEC
   types etc.  "

- Section 2.1.2: "IPv4 FEC Element Type" / "Prefix FEC element type"

NITs:
====
- Section 1: "Each LSR is indentified by an LDP identifier"/
                    "Each LSR is identified by an LDP identifier"

 - Section 1: "The last two octets of LDP Indentifers for platform-wide label spaces are always both
   zero." /
     "The last two octets of LDP Identifers for platform-wide label spaces are always both zero."

 - Section 1: "This document uses the following representation for LDP Indentifiers"/
             "This document uses the following representation for LDP Identifiers"

-  Section 1: "..created in the a single node" / "created in a single node"

 - Section 1:  "It may be also desirable for fate separation IPv4 and IPv6 LSP" /
  "It may be also desirable for fate separation of IPv4 and IPv6 LSP" /

- Section 1:   "Suc next-hop" / "Such next-hop"

 - Section 1:  "routing domains.Thus" / "routing domains. Thus"

- Section 2:
"Since the multi-instance procedures use same LDP Indentifer" /
"Since the multi-instance procedures use same LDP Identifer"

- Section 2.1.2: "Each Hello Adjacncies SHOULD " / "Each Hello Adjacency SHOULD"

- Section 3: "(VPLS)described" / "(VPLS) described"

- Section 3: "same FEC mapping has been already receiver over"/"same FEC mapping has been already received over"

- Section 3: "with statuc code"/"with status code"


Rgds,
-- Kamran


From: Eric Gray <[e-mail]<mailto:[e-mail]>>
Date: Friday, September 14, 2012 10:29 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] MPLS-RT review of [e-mail]<mailto:[e-mail]>

Dear Authors,

The MPLS Chair(s) have asked myself (and others) to review this draft to
determine – possibly among other things – whether this draft is ready for
adoption as a working group draft.

As an overview, I feel that this draft needs a few important "direction
changes" before it will be ready to adopt by the working group, assuming
the working group decides that this is work that we have both interest and
capacity to work on.

I first tried to determine if this work is appropriate for the working group.
It appears that the MPLS charter is very much out of date, so this item –
along with the 25+ drafts already adopted as working group drafts (in
various degrees of completion) – does not appear as a charter item.

Which is a good segue to the topic – "can the working group actually do
this – along with the work they currently have already."  If every WG
participating member were to read all of the currently adopted drafts
in preparation for each IETF meeting, they could expect to spend 2 to
3 weeks out of every 4 months doing nothing else.

Possibly this is a bit much to expect.  I suspect this is a question for the
active participants in the MPLS working group to consider as a general
issue.

As a second general issue, this draft describes what I feel are fairly well
known rules that an implementation may follow to ensure that their
"cheating ways" are not discovered in some pathological way by other
implementations.

This seems to be the major contribution in section 2 of this draft.

In this sense, I'd be more comfortable if this draft were targeted to
become a BCP, rather than a Standard.

But, enough of the general issues; on to the specifics of this draft…

Major issues:

The third paragraph of the introduction is incorrect.  When peering
with an LSR that uses two LSR IDs, it is possible for that LSR to do this
in a way that makes it  difficult (if not impossible) for a peer to detect
that the two LSR IDs identify LSR functions of the same physical node.

In fact, to ensure the highest probability of compatibility (or the
lowest probability of compatibility issues), any LSR implementation
that uses more than one LSR ID should do this.  That means they need
to use separate IP addresses for discovery, session establishment, etc.

This is an example of a standards implementation axiom that amounts
to this: "if you're going to cheat, be careful not to get caught."

If implementers follow this rule through proper use of addressing, and
a few other things, then support for multiple LDP sessions just works,
today – without requiring further standardization work.

For the case where the label space portion of the LSR ID is zero (the
so-called platform-wide label space), the implementation that has
multiple LSR IDs needs to be careful about allocating labels in different
LDP Sessions – but this is an implementation robustness issue, not a
standards issue.

It is my opinion that the draft authors have not given sufficient thought
to what can be done using the current standards and a few common
sense implementation rules.
__________________________________________________________

I believe the direction taken in section 3 – toward greater visibility of the
fact that an LSR node has multiple LDP instance – is a mistake.

The authors have provided no example use case to support the assertion
that a loop may be formed as a result for "some applications" with a
properly implemented LSR.

In my opinion, this draft needs to provide explicit examples of where a
properly implemented/compliant LDP implementation would cause a
pathological outcome if it is implemented in such a way that a peer is
not able to detect that multiple LDP instances are implemented by a
common physical node.

Minor issues and Comments/Questions:

For the paragraph that starts on page 3 and continues onto page 4, the
first sentence has a number of problems and does not parse without
making some assumptions as to what the author(s) mean to say.

In addition, it would be useful if you could expand slightly on what you
mean by "routable"  IP addresses.  To be more precise, the 32-bit part
of the LSR ID that is typically used corresponds to an IP address (one of
potentially very many) that is assigned to the LSR node.

In fact, common implementation considerations frequently lead to a
preference to use the router ID (typically based on an internal assigned
"loop-back" IP address) – for much the same reasons that routers use
these addresses (i.e. they are less likely to be impacted by removal of
a physical interface).

If an IPv4 address assigned to the LSR is used for this purpose, it is
clear that the address is not only routable by assigned to a specific
network entity.
________________________________________________________

In section 2, it looks as if we are conflating the meaning of "label space"
(as a number – zero, in this case), "label context" (not necessarily tied
to the label-space number, but definitely tied to an LDP session) and
data plane.

As long as implementations observe certain rules, there is no problem
in using the existing protocol specifications when labels are assigned in
association with an active session and apply to a common subset of
interfaces (possibly including all interfaces).

For example, as long as the same label is not issued by two (or more)
LSR instances with a different semantic meaning, that label does not
present any problems when used (as intended) in the common data
plane.

The obvious method for doing this is for all LSR instances to share a
common label management function – for at least the case where
labels allocated may have meaning across multiple interfaces.  This
has been done in LDP implementations since before RFC 3036 (the
predecessor to RFC 5036) was published.

Note that this is an implementation choice.
_________________________________________________________

NITs:

In the Introduction, in (I believe) the 4th sentence of the 2nd paragraph,
"4 octets" should be "first 4 octets" (the preceding sentence talks about
the 6-octet LSR ID and the next sentence talks about the last 2 octets).

The sentence, in the penultimate paragraph of section 1 (Introduction),
that starts "Suc next-hop addresses" was probably meant to say "Such
next-hop addresses" – and there is probably supposed to be a space
after the period in that sentence and before the first word ("Thus") of
the next sentence.

--
Eric