Re: [Mpls-review] MPLS-RT review of draft-raza-mpls-ldp-applicability-label-adv

Hi Yaacov,

>> There is one point that I would raise with the authors and their extensions to RFC5036 Section 3.5.3 - I think it would be helpful if the authors
>> explicitly addressed the final sentence in the description of the A bit and explained how to support an LSR that the mode that is being forced on it
>> is "unacceptable".  During the Initialization of the session there is a possibility for the LSR to reject the session, but in the proposal, it seems that >> a particular application may use a mode that was not agreed as part of the initialization.

The matter of "acceptance" and "non-acceptance" only applies when mode "negotiation" applies to a FEC/application. As per out draft, the negotiated mode currently really applies to the "IP Prefix" FEC/application. So, the final sentence in the section 3.5.3. Of RFC 3036 still hold/apply as-is to this FEC.

For the FEC/applications with "forced" mode for their advertisement, there is no "negotiation" and hence they ALWAYS operate in a given mode for a given FEC/application (even on a shared session).

I can add following new subsection 4.3 in the draft to make it clear

"4.3 Unacceptable mode:

The procedures related to unacceptable label advertisement mode defined in RFC-5036 section 3.5.3 continue to apply for any "session mode-bound" FEC/applications. For "session mode-independent" FEC/applications, there is no negotiation and both LSRs MUST operate in the same/given mode as specified by their respective specification. For a session jointly shared amongst mode-bound and mode-independent FEC/applications, an unacceptable mode (between LSRs) for a given mode-bound FEC/application type will cause session to not establish, as per RFC-5036 section 3.5.3"

Comments ?

Rgds,
-- Kamran
From: Yaacov Weingarten <wyaacov@gmail.com<mailto:wyaacov@gmail.com>>
Date: Mon, 2 Jul 2012 17:36:15 +0300
To: Ross Callon <rcallon@juniper.net<mailto:rcallon@juniper.net>>
Cc: Nischal Sheth <nsheth@juniper.net<mailto:nsheth@juniper.net>>, Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>>, "thomas.morin@orange.com<mailto:thomas.morin@orange.com>" <thomas.morin@orange.com<mailto:thomas.morin@orange.com>>, George Swallow <swallow@cisco.com<mailto:swallow@cisco.com>>, "mpls-review@ietf.org<mailto:mpls-review@ietf.org>" <mpls-review@ietf.org<mailto:mpls-review@ietf.org>>, Luca Martini <lmartini@cisco.com<mailto:lmartini@cisco.com>>, "Sami Boutros (sboutros)" <sboutros@cisco.com<mailto:sboutros@cisco.com>>, "Syed Kamran Raza (skraza)" <skraza@cisco.com<mailto:skraza@cisco.com>>, Nic Leymann <N.Leymann@telekom.de<mailto:N.Leymann@telekom.de>>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com<mailto:martin.vigoureux@alcatel-lucent.com>>, Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>
Subject: Re: [Mpls-review] MPLS-RT review of draft-raza-mpls-ldp-applicability-label-adv

Hi, all

I have read the draft and in general would say that it is coherent, useful, fills a void, and ready for WG adoption.

There is one point that I would raise with the authors and their extensions to RFC5036 Section 3.5.3 - I think it would be helpful if the authors explicitly addressed the final sentence in the description of the A bit and explained how to support an LSR that the mode that is being forced on it is "unacceptable".  During the Initialization of the session there is a possibility for the LSR to reject the session, but in the proposal, it seems that a particular application may use a mode that was not agreed as part of the initialization.

Aside from that there are several editorial corrections that should be performed that I will forward to the authors

BR,
yaacov weingarten

On Wed, Jun 20, 2012 at 5:14 PM, Ross Callon <rcallon@juniper.net<mailto:rcallon@juniper.net>> wrote:
You have been selected as an MPLS Review team reviewers for
draft-raza-mpls-ldp-applicability-label-adv.

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 July 11, 2012 (this is giving you an
extra week due to the July 4th holiday)?

Thanks, Ross
(as MPLS WG chair)

_______________________________________________
Mpls-review mailing list
Mpls-review@ietf.org<mailto:Mpls-review@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls-review