Subject: [mpls] Fwd: Re: MPLS-RT review of draft-kompella-mpls-rmr

From: Stewart Bryant <[email-masked]>
Date: Mon, 13 Jul 2015 17:29:04 +0100

Forwarding to the MPLS list

-------- Forwarded Message --------
Subject: 	Re: MPLS-RT review of draft-kompella-mpls-rmr
Date: 	Mon, 13 Jul 2015 17:27:33 +0100
From: 	Stewart Bryant <[email-masked]>
Reply-To: 	[email-masked]
To: 	Loa Andersson <[email-masked]>, Jie Dong <[email-masked]>, Sam 
Aldrin <[email-masked]>, Eric Gray <[email-masked]>, 
[email-masked], [email-masked] 
<[email-masked]>, [email-masked]

I am sorry this is late.

This is an interesting piece of work.

Given that it majors on topology and FRR and in many
ways MPLS is incidental, I wonder whether it would be
best progressed in MPLS or in RTGWG?

The proposal is essentially to construct rings
within a mesh network and use these for repair.

I am in two minds about the work. On the one hand one
could ask whether this is really needed given existing
work on FRR, on the other hand given that all repair
situations are by definition part of a ring sub-topology
this potentially has wider applicability than is
implied by the authors.

Given the above observations, I think that there needs
to be a much clearer applicability statement for this work.
The draft needs to call out the particular circumstances
in which a ring element of a mesh should be abstracted from
the mesh for special treatment in this
way. It would also be useful explain how the rest of the mesh
knows to treat this sub-topology differently.

The text itself is well written but I think the MPLS
WG needs to discuss the above issues and the chairs
need to discuss with the ADs and RTGWG chairs to decide
best place to pursue this work.

- Stewart

On 24/06/2015 17:03, Loa Andersson wrote:
> Stewart, Jie, Sam and Eric;
>
> You have be selected as MPLS-RT reviewers for draft-kompella-mpls-rmr-01.
>
> 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 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 July 9, 2015? Please respond in a
> timely fashion.
>
> Thanks, Loa
> (as MPLS WG chair)

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 15 Jul 2015 03:03:33 +0000

Forwarding to the MPLS list.

> -----Original Message-----
> From: Dongjie (Jimmy)
> Sent: Tuesday, July 14, 2015 10:30 AM
> To: 'Loa Andersson'; [email-masked]; Sam Aldrin; Eric Gray;
> [email-masked]; [email-masked]
> Subject: RE: MPLS-RT review of draft-kompella-mpls-rmr
> 
> Hi,
> 
> I’ve been selected to review draft-kompella-mpls-rmr-01 before the WG
> adoption call.
> 
> The document is coherent, well written and proposes general solution for
> auto-discovery and signaling of MPLS rings.
> 
> Below are my comments to the draft which are non-blocking to WG adoption
> call:
> 
> 1.1 Definitions
> 
> In the definition of Ring ID, it says "An RID of 0 means the node is a
> "promiscuous" node. Maybe some description of the relationship between the
> node and Ring ID could be added here, such as "Every node on a ring is
> configured with one or more RIDs".
> 
> 3.2 Ring Links and Directions
> 
> In 1st paragraph, it says "signaling messages and labels across one component
> link apply to all components", and multiple lambdas or fibers are given as
> example of parallel links. Does this ring lsp mechanism also applies to lambda or
> fiber switching LSPs? If so, maybe it is better to make this explicit in the
> introduction.
> 
> 3.7 Protection
> 
> The indication which propagates on the ring, does it carry some information of
> the failure location? Since when some failure occurs, the switchover of ring
> LSPs depends on the failure location, some LSPs may switch from CW to AC,
> while for some others switchover is not needed.
> 
> 4. Autodiscovery
> 
> Will the protocol extensions to IGP be part of this document, or as said in the
> abstract, "will be described in companion documents"? My personal feeling is
> the general mechanism could be specified in this document, while the detailed
> IGP extensions are more suitable for an IGP document.
> 
> 4.3 Mastership Phase
> 
> It says the master is determined by "the lowest loopback address of all nodes
> with the highest mastership values", if the mastership value of all nodes needs
> to be compared, does the mastership value also need to be carried in the IGP
> Ring TLVs?
> 
> Section 4.5 Ring Changes and Section 5 Ring Signaling, some text needs to be
> added in these two sections.
> 
> Besides, it is better that this document or the companion documents summarize
> the changes introduced to the IGP protocols, for example, the timer based
> multi-phase information advertisement.
> 
> Best regards,
> Jie
> 
> > -----Original Message-----
> > From: Loa Andersson [mailto:[email-masked]]
> > Sent: Thursday, June 25, 2015 12:03 AM
> > To: [email-masked]; Dongjie (Jimmy); Sam Aldrin; Eric Gray;
> > [email-masked]; [email-masked]
> > Subject: MPLS-RT review of draft-kompella-mpls-rmr
> >
> > 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.
> >
> > Loa Andersson                        email: [email-masked]
> > Senior MPLS Expert                          [email-masked]
> > Huawei Technologies (consultant)     phone: +46 739 81 21 64