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

From: Kireeti Kompella <[email-masked]>
Date: Tue, 8 Sep 2015 12:25:13 -0700

Hi All,

Thanks all again for your comments.

I've just posted a new version incorporating all your feedback.  There is
new text to clarify some points, and the text on unsolicited ARP and Async
operation have been merged.  The one thing left to do is to write the MPLS
Fabric document -- work has started here.

Kireeti.

On Wed, Jul 15, 2015 at 6:11 PM, Sriganesh Kini <[email-masked]
> wrote:

> Hello,
>
> This is the MPLS-RT review of draft-kompella-mpls-larp -
>
> The document is coherent.
>
> Regarding whether it is useful (i.e., is it likely to be actually useful
> in operational networks), the yet to do be defined reference
> [TODO-MPLS-FABRIC] would be needed before commenting on it. Also if any
> host NIC vendors can chime in or any evidence of host operating systems
> that plan to support this is present, it will help to answer this question.
> I don't see any technical reason why MPLS shouldn't be useful in DC
> networks.
>
> The document is technically sound for most parts, but as sec 4 points out
> there are a number of issues still left. I would add a couple issues -
>         1.      The restarts should address control-plane restart as well.
> Though there is no session between server and client, the action (if any)
> to be performed when control-plane restarts should be specified.
>         2.      If a LSR (L-ARP server) goes down, then there should be a
> proposed resiliency mechanism (e.g. using BFD).
>
> Other comments:
>         1.      It would be very useful to list the use-cases where a host
> wants to participate in the fabric through a simpler mechanism than RSVP-TE
> UNI. Additionally, even though label distribution itself may become simpler
> using ARP, doesn't the host have to do other MPLS OAM functionality? Some
> discussion of this topic is needed.
>         2.      Section 3.4 "... presence of a complex topology...". Which
> topology is this referring to ? Is it the underlying ethernet network
> topology ? Pls state it explicitly and also why it would cause a problem to
> LARP.
>
> Nits:
>         1.      Section 1, page 1 s/Centre/Center
>         2.      The node 'T' should be shown in the MPLS Fabric of Fig 1.
>         3.      Missing reference [TODO-MPLS-FABRIC]
>         4.      Sec 3.4 "Seamless MPLS" reference is missing.
>
> Since [TODO-MPLS-FABRIC] seems to the primary driver for this document, it
> would be better to consider this for a WG document after that document is
> published.
>
> - Sri
> ________________________________________
> From: Loa Andersson [[email-masked]]
> Sent: Tuesday, 30 June 2015 9:18 AM
> To: Lucy yong; Kamran Raza (skraza); Sriganesh Kini; Aissaoui, Mustapha
> (Mustapha); [email-masked];
> [email-masked]
> Subject: MPLS-RT review of draft-kompella-mpls-larp
>
> Lucy, Kamran, Sri and Mustapha;
>
> You have be selected as MPLS-RT reviewers for draft-kompella-mpls-larp.
>
> 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 14, 2015? Please respond in a
> timely fashion.
>
> Thanks, Loa
> (as MPLS WG chair)
> --
>
>
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>

-- 
Kireeti

---

From: Loa Andersson <[email-masked]>
Date: Thu, 10 Sep 2015 11:35:33 +0200

Lucy, Kamran, Sri and Mustapha

Can each of you confirm to me that your MPLS-RT review comments has been
satisfactorily addressed.

I will start the working group adoption poll as soon as I have 
your¨resonses,

/Loa

On 2015-09-08 21:25, Kireeti Kompella wrote:
> I've just posted a new version incorporating all your feedback.  There
> is new text to clarify some points, and the text on unsolicited ARP and
> Async operation have been merged.  The one thing left to do is to write
> the MPLS Fabric document -- work has started here.
>
> Kireeti.
>
> On Wed, Jul 15, 2015 at 6:11 PM, Sriganesh Kini
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello,
>
>     Regarding whether it is useful (i.e., is it likely to be actually
>     useful in operational networks), the yet to do be defined reference
>     [TODO-MPLS-FABRIC] would be needed before commenting on it. Also if
>     any host NIC vendors can chime in or any evidence of host operating
>     systems that plan to support this is present, it will help to answer
>     this question. I don't see any technical reason why MPLS shouldn't
>     be useful in DC networks.
>
>     The document is technically sound for most parts, but as sec 4
>     points out there are a number of issues still left. I would add a
>     couple issues -
>              1.      The restarts should address control-plane restart
>     as well. Though there is no session between server and client, the
>     action (if any) to be performed when control-plane restarts should
>     be specified. 
>              2.      If a LSR (L-ARP server) goes down, then there
>     should be a proposed resiliency mechanism (e.g. using BFD). 
>
>     Other comments:
>              1.      It would be very useful to list the use-cases where
>     a host wants to participate in the fabric through a simpler
>     mechanism than RSVP-TE UNI. Additionally, even though label
>     distribution itself may become simpler using ARP, doesn't the host
>     have to do other MPLS OAM functionality? Some discussion of this
>     topic is needed. 
>              2.      Section 3.4 "... presence of a complex
>     topology...". Which topology is this referring to ? Is it the
>     underlying ethernet network topology ? Pls state it explicitly and
>     also why it would cause a problem to LARP. 
>
>     Nits:
>     Since [TODO-MPLS-FABRIC] seems to the primary driver for this
>     document, it would be better to consider this for a WG document
>     after that document is published.
>
>     - Sri
>     From: Loa Andersson [[email-masked] <mailto:[email-masked]>]
>     To: Lucy yong; Kamran Raza (skraza); Sriganesh Kini; Aissaoui,
>     Mustapha (Mustapha); [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>     <tel:%2B46%20739%2081%2021%2064>
>
>
>
>
> --
> Kireeti

---

From: Lucy yong <[email-masked]>
Date: Thu, 10 Sep 2015 21:28:34 +0000

Thank authors for the update. It is better/clearer.

I am fine with the WG adoption on this version but have some comments/suggestions to this version.

·         Section 3.2 should make a general case. Tx that wants an attached node to have MPLS reachability, allocates a label to reach the node and advertises the label into the MPLS Fabric or to local subnet via LARP. Upon receiving a packet with the label from the fabric or the local subnet, Tx pops the label and sends the packet to the node. Note that Tx can allocate more than one label for the node and advertise to the MPLS fabric. This is normal MPLS behavior.

·         Should clarify that Tx devices MUST be configured as a host to the local network, i.e. not a bridge device. It MUST terminate/discard a locally received packet.

·         In security section, it should mention that a packet with a label sent by a host may be delivered by the local network as an unknown packet; thus more than one T device will get the packet. If a T device that is not the destination of a packet receives the packet and accidently takes an action on the packet, this will cause a major error.

·         It is important to address the client-server sync and withdrawing process in this mechanisms

·         A host may be configured a gateway address to send packet outside the subnet. It would be nice to state out the operation at T device in this case.

·         Text: This field is valid only in an L-ARP reply message.  Does it mean LST and ATT TLVs will be presented or not presented in the request msg? Please make the word very clearly.

·         The metric is a well-known parameter for network element, but not a host. When host supporting LARP sends a response, what is the recommendation to fill the ATT TLV? The draft should specify that for the integrity.

·         Replace “client must not insert” with “client MUST NOT insert” in section 9.

Regards,

Lucy

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, September 10, 2015 4:36 AM
To: Kireeti Kompella; Sriganesh Kini
Cc: Lucy yong; Kamran Raza (skraza); Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]; [email-masked]
Subject: Re: MPLS-RT review of draft-kompella-mpls-larp

Can each of you confirm to me that your MPLS-RT review comments has been satisfactorily addressed.

I will start the working group adoption poll as soon as I have your¨resonses,

/Loa

> is new text to clarify some points, and the text on unsolicited ARP

> and Async operation have been merged.  The one thing left to do is to

> write the MPLS Fabric document -- work has started here.

> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:

>              2.      The node 'T' should be shown in the MPLS Fabric of

>     Fig 1.

>     Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>

>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>     Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

>     Senior MPLS Expert [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 15 Sep 2015 09:17:11 -0700

Loa,

I am fine with the resolutions in -04 except for one, for which I would
like the guidance of the WG chairs. As stated in the abstract, this draft
is providing a solution as a component of the MPLS Fabric architecture
which will be defined in the yet to be published draft [TODO-MPLS-FABRIC].
Shouldn't the order of WG acceptance be architecture first and then
specific solutions?

Thanks
Sri

On Thu, Sep 10, 2015 at 2:35 AM, Loa Andersson <[email-masked]> wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 17 Sep 2015 11:39:33 +0200

Sri,

I certainly want to hear from the working group, my co-chairs and
the authors on this, before we make the call on this issue.

I tend to think that we should have the first individual draft on
the MPLS fabric architecture available before starting the the adoption
poll and the MPLS fabric architecture as a wg doc before going to
working group last call.

Thoughts? Anyone?

/Loa

On 2015-09-15 18:17, Sriganesh Kini wrote:
> like the guidance of the WG chairs. As stated in the abstract, this
> draft is providing a solution as a component of the MPLS Fabric
> architecture which will be defined in the yet to be published draft
> [TODO-MPLS-FABRIC]. Shouldn't the order of WG acceptance be architecture
> first and then specific solutions?
>
> Thanks
> Sri
>
> On Thu, Sep 10, 2015 at 2:35 AM, Loa Andersson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>              Hello,
>
>              From: Loa Andersson [[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>]
>         <mailto:[email-masked]>
>              <mailto:[email-masked]
>         <mailto:[email-masked]>>;
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>              Loa Andersson                        email:
>         [email-masked] <mailto:[email-masked]>
>              <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>              Huawei Technologies (consultant)     phone: +46 739 81 21
>         64 <tel:%2B46%20739%2081%2021%2064>
>     [email-masked] <mailto:[email-masked]>