Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-ldp-adj-capability

From: Markus Jork <[email-masked]>
Date: Mon, 17 Sep 2012 17:25:11 -0400

Here is my review team feedback on draft-pdutta-mpls-ldp-adj-capability:

a) Is it coherent?

The introduction provides a good description of what the goal of this
LDP extension is and why it may be useful.

There are various typos and grammatical errors in this document. Cleaning
that up would provide a much better reading experience.

b) Is it useful?

I am guessing a major motivation for creating this draft was to provide
support for draft-pdutta-mpls-multi-ldp-instance? Of course the draft
provides examples of other use cases, but it seems to me those could
often be achieved by local configuration on the routers.

I feel this draft should only be advanced to WG document status if there 
is another WG spec that clearly needs it or greatly benefits from it.

Without a specific, compelling use case adopted by the WG, the draft
just provides a "nice to have" feature. And that should place it pretty
low on the priority list for WG work.

c) Is it technically sound?

There is no mention at all of the S-bit (state bit) in the capability
parameter TLVs. The mechanism specified in the draft to exclude
a capability on an interface seems to be:

- advertise that capability for the session
- do not advertise that capability for the hello adjacency
- do advertise some other capabilities on the hello adjacency (to
  demonstrate that the per-adjacency capability mechanism is in use)

I think the draft needs some statements regarding the S-bit and whether
that can be used to disable a capability on an adjacency or not.

At the end of section 3, the following is noted:

> Note that it may be possible to define some capabilities in future
> that may not be applicable to ber advertised by LDP session but only
> over the Hello Adjacency.  Such capabilities are out of scope of this
> document.

It may be ok to leave that out of scope. But the way the specification
is written right now (always requiring the capability to be advertised
for the session) seems to make it unnecessarily difficult to add such
capabilities in the future.

Wouldn't it be simpler overall to use the S-bit to explicitly enable
or disable a capability for the adjacency? If the TLV is totally absent,
the session settings would take effect. The last paragraph in section 4
of the draft may explain why this is not a good idea. But I don't
really understand that paragraph. Can you elaborate? 

-Markus

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 24 Sep 2012 03:19:50 -0400

Hello Pranjal and other authors,

Summary of review -
1. Is the doc coherent - Yes (except one of the use-cases - see detailed review)
2. Is it useful - Maybe. Needs some service providers feedback (see detailed review)
3. Is it technically sound - Mostly. Some open questions are listed in detailed review.
4. Is it ready to be adopted as a WG doc - The doc is a good start but it would be very useful for it to go through a round of refinement (especially the usefulness factor) before being put up for WG adoption.

Detailed review
1. The use-case of 'Case 1 in section 1', states that IF1, IF2 and IF3 are either IPv4 or IPv6 interfaces but not dual-stack and further states that all three interfaces are capable of setting up IPv4 FEC elements (Since LDP follows IGP this implies that all three interfaces are enabled for IPv4 forwarding). But since it is stated earlier that the interfaces are not dual-stack, wouldn't this imply that the interface is not IPv6 capable and hence would not be IPv6 FEC capable either ? This does not seem to be the intent of the use-case. Can you simplify/clarify the wording in this use-case.  

2. In the above use-case it is also stated that an operator may configure it to be so. Can we get some operator feedback on why they may explicitly choose such a configuration.

3. The use-case of 'Case 2 in section 1' is same as use-case in sec 2.1.3 of draft-pdutta-mpls-multi-ldp-instance but that doc is not a WG yet. Can we get some operator feedback on whether the fate-separation of v4/v6 traffic is useful even though both IF1 and 2 are dual-stack capable. What happens if one of the interfaces goes down and the other must be used as a backup ?

4. If the hello adj is not tied to a specific interface (e.g. in targeted sessions) is this draft still applicable ? If not it would be useful to explicitly state that.

5. What is the relation of the traffic separation techniques offered by this doc when compared to other techniques such as multi-topology ? Are there any advantages here ?

6. TFC is an TLA that has been used in RFC 4303. Use something different.

7. There are some nits such as "... to ber advertised...", "... reflecting then change..."

Thanks

- Sri
________________________________________
From: Loa Andersson [[email-masked]]
Sent: Thursday, August 30, 2012 3:16 AM
To: Sriganesh Kini; [email-masked]; Vero Zheng; Markus Jork; [email-masked]; Martin Vigoureux
Cc: [email-masked]
Subject: MPLS-RT review of draft-pdutta-mpls-ldp-adj-capability

Sri, Bo Wu, Vero and Markus

You have been selected as an MPLS Review team reviewers for
draft-pdutta-mpls-ldp-adj-capability-00.txt.

Note to authors: You have been CC’d on this email so that you can know
that this review is going on. However, please do not review your own
document.

Reviews should comment on whether the document is coherent, is it useful
(ie, is it likely to be actually useful in operational networks), and is
the document technically sound?  We are interested in knowing whether
the document is ready to be considered for WG adoption (ie, it doesn’t
have to be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and
secretary, and CC’d to the MPLS WG email list. If necessary, comments
may be sent privately to only the WG chairs.

Are you able to review this draft by Sep 17, 2012?

Thanks, Loa
(as MPLS WG chair)
--

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13