Re: [mpls] MPLS-RT review od draft-smack-mpls-rfc4379bis

[Kireeti Kompella <[e-mail]>]

Copying MPLS WG list ... this is Curtis's review, and Carlos's reply.

Thanks, Curtis, for your detailed review; I agree with most of your points,
but not really on GAL.  I think that should be taken up in a separate
thread -- George had a comment on this as well.

As for how much change should be incorporated into the draft _before_ vs
_after_ WG adoption, here's my take:
a) the deprecations (esp DSMAP) (including moving these into an appendix)
be dealt with before making this a WG doc;
b) draft-ietf-mpls-entropy-lsp-ping NOT be included in the bis draft (but
perhaps state that a future RFC will define how label-based ECMP will be
done);
c) RFC 6425 only be included if there is adequate implementation and
deployment experience.

Kireeti.

On Sun, Dec 6, 2015 at 10:06 PM, Carlos Pignataro (cpignata) <
[e-mail]> wrote:

>
> > On Dec 5, 2015, at 1:39 PM, Curtis Villamizar <[e-mail]>
> wrote:
> >
> > Oops.  Original sent from an email address not subscribed to the MPLS
> > mailing list.  Sorry for duplicates (again).
> >
> > Curtis
> >
> >
> > In message <[e-mail]>
> > Curtis Villamizar writes:
> >
> > Hello Loa and friends,
> >
> > The MPLS WG should definitely take on draft-smack-mpls-rfc4379bis as a
> > WG item.
>
> Thanks for the support of this work, Curtis.
>
> > An update to RFC 4379 is long overdue.  RFC 4379 was
> > published in 2006, in draft since about 2002 I think and is updated by
> > seven RFC, some of which obsolete or change the early TLVs and
> > subTLVs.  There are also seven erratta.
> >
> > Currently someone who wants to implement or just understand how LSP
> > ping and traceroute work they have to read this RFC and then ignore a
> > lot of it and read 7 others plus some errata if implementing.
> >
>
> I agree.
>
> > In particular RFC6424 depricates the original Downstream Mapping TLV
> > and replaces it with Downstream Detailed Mapping TLV and Multipath
> > Data Sub-TLV.  While this is mentioned in the ToDo section, it has not
> > been done.  Clearly this document should be folded into the update and
> > Downstream Mapping TLV fully deprecated.
>
> Ack — planed for after adoption.
>
> >
> > RFC6425 which adds P2MP via changes in semantics and add some more
> > Sub-TLVs (RSVP P2MP IPv4 Session Sub-TLV, RSVP P2MP IPv6 Session
> > Sub-TLV, Multicast LDP FEC Stack Sub-TLVs, etc).
> >
> > RFC6426 extends RFC 4379 for the purpose of MPLS-TP on-demand ping
> > (aka CV) and traceroute.  This is accomplished by adding DSMAP/DDMAP
> > Non-IP, Source/Destination Identifier TLV, Static LSP Sub-TLV, Static
> > Pseudowire Sub-TLV, and some new semantics.  It might be best to leave
> > RFC6426 separate since RFC6426 supports a set of capabilities that may
> > not be of interest to the majority of MPLS deployments (non-IP
> > addressing, no control plane) but are stated requirements for MPLS-TP.
>
> Also my take, but we should ask the WG.
>
> >
> > RFC6829 adds IPv6 LDP PW FEC support.  This is with renaming to
> > Pseudowire IPv4 Target FEC Stack Sub-TLVs and adding Pseudowire IPv6
> > Target FEC Stack Sub-TLVs.  It would also be nice if FEC 128 was fully
> > depricated.  It looks like this is already folded into rfc4379bis.
> >
>
> Yes.
>
> > RFC7506 defines the IPv6 Router Alert Option for MPLS OAM.  As I
> > understand things, the direction today is towards using GAL (RFC5586)
> > for MPLS OAM as described in RFC7708 (for PW VCCV).  See Section 4.1.
> > (Relationship with Existing MPLS OAM Alert Mechanisms) in RFC5586.
> > While at the time of publication GAL was an alternative to router
> > alert and TTL, it is my understanding the GAL and TTL (for traceroute)
> > are the current preferred alternative.  The update to RFC 4379 should
> > address this issue, at least to acknowledge GAL, but perhaps to
> > recommend GAL as the preferred option.  This way GAL is no longer a
> > MUST for MPLS-TP and a MAY for plain old MPLS and PW.
> >
> > RFC7537 just adds an IANA registry for the codepoints in MPLS lsp and
> > traceroute.  RFC7537 could be obsoleted by adding an IANA section to
> > rfc4379bis making one less document to find and look through.
> >
> > An update to RFC 4379 (and RFC6424) should also incorporate the
> > changes made in draft-ietf-mpls-entropy-lsp-ping which covers use of
> > Entropy Labels (EL) and draft-ietf-mpls-lsp-ping-lag-multipath which
> > covers Link Aggregation Group (LAG) Interfaces.  The former adds a
> > label FEC.  The latter adds some TLVs and subTLVs.  It would be up to
> > the authors whether they want to merge but it would be better to put
> > these extensions in the base document.
>
> Good point.
>
> >
> > A diff using http://tools.ietf.org/rfcdiff shows very little
> > substantive difference between RFC 4379 and rfc4379bis.  Mostly the
> > changes are the inclusion of a incomplete ToDo section and none of
> > which have been done except folding the RFC6829 IPv6 changes in.
> >
> > Minor - On the list there was some comments about clarity of section
> > 4.4.1. (FEC Validation).  I think the comment was regarding why a Nil
> > FEC could occur.  Perhaps some explanation would help, maybe just a
> > comment in the procedural outline in this section.
> >
> > So this document should definitely be a WG item, maybe after taking
> > care of some of the ToDo items, maybe as-is.  That would be something
> > the WG chairs probably should decide with input from others in the WG.
> > Either way, the ToDo list needs to be taken care of and maybe a few
> > more drafts added to the ToDo list.  I did not check the errata.
> >
> > Curtis
> >
>
>
> Thanks again, Curtis!
>
> — Carlos.
>
> >
> >
> > In message <[e-mail]>
> > Curtis Villamizar writes:
> >
> > Hi Loa, Lizhong,
> >
> > I'm replying to the email from Lizhong because I misplaced Loa's
> > original.  Oops.
> >
> > Dec 6 should be OK.
> >
> > Curtis
> >
> >
> > In message <[e-mail]>
> > Lizhong writes:
> >>
> >> Hi Loa,
> >> Should be OK for me. Thanks.
> >>
> >> Regards
> >> Lizhong
> >>
> >>>
> >>> Lizhong, Yimin, Curtis, and  Dave,
> >>>
> >>>
> >>> You have been selected as MPLS-RT reviewers for
> draft-smack-mpls-rfc4379bis.
> >>>
> >>> 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).
> >>>
> >>> This MPLS-RT review is a bit different in that it is a bis-version of
> >>> a widely implemented and deployed protocol, however the basic question
> >>> is the same - are we ready to adopt it as a wg document? If the meet
> >>> all the criteria LSP Ping will be progressed to Internet Standard.
> >>>
> >>> Reviews should be sent to the document authors, WG co-chairs and WG
> >>> secretary, and CC'd to the MPLS WG email list. If necessary, comments
> >>> may be sent privately to only the WG chairs.
> >>>
> >>> If you have technical comments you should try to be explicit about what
> >>> needs to be resolved before adopting it as a working group document,
> and
> >>> what can wait until the document is a working group document and the
> >>> working group has the revision control.
> >>>
> >>> Are you able to review this draft by December 6, 2015? Please respond
> >>> in a timely fashion.
> >>>
> >>> Thanks, Loa
> >>> (as MPLS WG chair)
> >>>
> >>>
> >>> --
> >>>
> >>>
> >>> Loa Andersson                        email: [e-mail]
> >>> Senior MPLS Expert                          [e-mail]
> >>> Huawei Technologies (consultant)     phone: [phone]
>
>


-- 
Kireeti