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

From: Xufeng Liu <[email-masked]>
Date: Fri, 3 Dec 2021 16:28:10 -0500

Hi Authors,

I have reviewed the document and I think that the document is useful by
addressing a gap for network operations. The approach is technically sound
and easily implementable. The document is coherent. It is ready to be
considered for WG adoption.

Here are a few comments that can wait until the WG adoption.

1. The aging/timeout mechanism used by Ethernet ARP is not mentioned in
this document. Is it intended to recommend implementing such a mechanism?

2. It is understandable that the initial use case came from MPLS over
Ethernet, but is this mechanism Ethernet dependent, or usable for other
types of hardware (at least in theory)?

3. Sec 3.3. says that “1. checks if it has reachability to H3.” Is this
check for “IP reachablity”, or MPLS reachability with an available
lable stack that can be used to reach H3?

4. In Figure 3. of Sec 5.1., there is “ ... (3 octets)”. Should it be “2
octets” here? Also, if these 2 octets are not used, why 6 is chosen as the
hardware address length?

Thanks,

- Xufeng

On Mon, Nov 8, 2021 at 11:19 AM Tarek Saad <[email-masked]> wrote:

> Hi Xufeng/Yingzhen/Rakesh,
>
>
>
> You have been selected as potential MPLS-RT reviewers for
> draft-kompella-mpls-larp-10.
>
>
>
> Note to authors: You have been CC'd on this email so that you can know
> that this review is going on.
>
>
>
> 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
> *really* need 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.
>
>
>
>
>
> Can you review the document by November 26, 2021?
>
>
>
> Regards,
>
> Tarek (as MPLS WG chair)
>

---

From: Rakesh Gandhi <[email-masked]>
Date: Sun, 5 Dec 2021 12:14:29 -0500

Hi Tarek, Authors,
As requested, I have done MPLS-RT review of draft-kompella-mpls-larp-10.

Yes, the document is coherent and technically sound. It is well written and
is ready to be considered for WG adoption.
Below are some non-blocking review comments to be considered:

 3 <https://datatracker.ietf.org/doc/html/draft-kompella-mpls-larp-10#section-3>.
L-ARP Protocol Operation

Within the MPLS Fabric, the usual MPLS protocols (IGP,

   LDP, RSVP-TE) are run.

<RG> Does this include SR-MPLS as well?

3.2 <https://datatracker.ietf.org/doc/html/draft-kompella-mpls-larp-10#section-3.2>.
Egress Operation

o  a node SID advertised on behalf of H3; or

<RG> The draft should expand the acronym for SID.

Is this for Segment Routing? The draft does not discuss SR applicability
elsewhere (e.g. Section 3).  Also there is no reference to any SR documents.

3.4 <https://datatracker.ietf.org/doc/html/draft-kompella-mpls-larp-10#section-3.4>.
Data Plane

If T1's reachability to H3 is via a

   SPRING label stack, the label L1 acts as an implicit binding SID.

<RG> Same Comment for binding SID and SPRING as above.

Section 5.2

The CT TLV has Type (TBD)

Is this Type TBD to be allocated by IANA? If yes, Section 7 does not
mention it.

Also, should expand the acronym CT.

Section 7 IANA Section:

The document may add more information on the IANA registry type. I think it
is following:

https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml

Hardware Types

Thanks,

Rakesh

---

From: Tarek Saad <[email-masked]>
Date: Mon, 13 Dec 2021 15:28:45 +0000

Thanks for all reviewers for taking the time to review and give feedback.

Authors, please work with reviewers on addressing all blocking comments and advise back.

Regards,
Tarek (as MPLS WG co-chair)

From: Rakesh Gandhi <[email-masked]>
Date: Sunday, December 5, 2021 at 12:14 PM
To: Xufeng <[email-masked]>
Cc: Tarek Saad <[email-masked]>, "[email-masked]" <[email-masked]>, MPLS Working Chairs <[email-masked]>, "[email-masked]" <[email-masked]>, mpls <[email-masked]>
Subject: Re: MPLS-RT for draft-kompella-mpls-larp

Hi Tarek, Authors,

Yes, the document is coherent and technically sound. It is well written and is ready to be considered for WG adoption.
Below are some non-blocking review comments to be considered:

 3<https://datatracker.ietf.org/doc/html/draft-kompella-mpls-larp-10#section-3>.  L-ARP Protocol Operation

   LDP, RSVP-TE) are run.

3.2<https://datatracker.ietf.org/doc/html/draft-kompella-mpls-larp-10#section-3.2>.  Egress Operation

<RG> The draft should expand the acronym for SID.
Is this for Segment Routing? The draft does not discuss SR applicability elsewhere (e.g. Section 3).  Also there is no reference to any SR documents.

3.4<https://datatracker.ietf.org/doc/html/draft-kompella-mpls-larp-10#section-3.4>.  Data Plane

Section 5.2

Is this Type TBD to be allocated by IANA? If yes, Section 7 does not mention it.
Also, should expand the acronym CT.

Section 7 IANA Section:

The document may add more information on the IANA registry type. I think it is following:

Thanks,
Rakesh

On Mon, Nov 8, 2021 at 11:19 AM Tarek Saad <[email-masked]<mailto:[email-masked]>> wrote:
Hi Xufeng/Yingzhen/Rakesh,

You have been selected as potential MPLS-RT reviewers for draft-kompella-mpls-larp-10.

Note to authors: You have been CC'd on this email so that you can know that this review is going on.

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 *really* need 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.

Regards,
Tarek (as MPLS WG chair)

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 13 Dec 2021 18:36:00 -0800

Hi Xufeng,

Thanks for your review.  Please see inline for replies.

> On Dec 3, 2021, at 13:28, Xufeng Liu <[email-masked]> wrote:
> 
> Hi Authors,
> I have reviewed the document and I think that the document is useful by addressing a gap for network operations. The approach is technically sound and easily implementable. The document is coherent. It is ready to be considered for WG adoption.
> 1. The aging/timeout mechanism used by Ethernet ARP is not mentioned in this document. Is it intended to recommend implementing such a mechanism?
> 

Thanks for this reminder!  We will add more on this in a future revision.
> 2. It is understandable that the initial use case came from MPLS over Ethernet, but is this mechanism Ethernet dependent, or usable for other types of hardware (at least in theory)?
> 

This mechanism is general.  However, the details for MPLS over some other hardware type may be a little bit different (for example, depending on the media, the hardware address may contain media addresses in addition to labels).  So, for now, the focus is on MPLS over Ethernet.
> 3. Sec 3.3. says that “1. checks if it has reachability to H3.” Is this check for “IP reachablity”, or MPLS reachability with an available lable stack that can be used to reach H3?
> 

Fixed.
> 4. In Figure 3. of Sec 5.1., there is “ ... (3 octets)”. Should it be “2 octets” here? Also, if these 2 octets are not used, why 6 is chosen as the hardware address length?
> 

3 octets (clarified).
> Thanks,
> - Xufeng
> 
> On Mon, Nov 8, 2021 at 11:19 AM Tarek Saad <[email-masked] <mailto:[email-masked]>> wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 13 Dec 2021 19:16:57 -0800

Hi Rakesh,

Thanks for your review!  See inline for replies.

:k

> On Dec 5, 2021, at 09:14, Rakesh Gandhi <[email-masked]> wrote:
> 
> Hi Tarek, Authors,
>   3 <https://datatracker.ietf.org/doc/html/draft-kompella-mpls-larp-10#section-3>.  L-ARP Protocol Operation
>  

It does; references and text added.

> 3.2 <https://datatracker.ietf.org/doc/html/draft-kompella-mpls-larp-10#section-3.2>.  Egress Operation
>  

Fixed.
 
> 3.4 <https://datatracker.ietf.org/doc/html/draft-kompella-mpls-larp-10#section-3.4>.  Data Plane
>  

Fixed.

> Also, should expand the acronym CT.

Both fixed.

> https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml <https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml>
>  <>Hardware Types
> 

Correct.  Added reference, and a request for TLV registry.

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 13 Dec 2021 19:20:58 -0800

Hi Tarek,

I’ve updated the draft (version -11) with the review comments from Xufeng and Rakesh.  I may have missed a review from Yingzhen.

Are we ready to adopt this as a WG doc?

Thanks,
:k

> On Dec 13, 2021, at 07:28, Tarek Saad <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>

---

From: Kireeti Kompella <[email-masked]>
Date: Sun, 19 Dec 2021 09:48:18 -0800

Hi Xufeng,

> On Dec 13, 2021, at 18:36, Kireeti Kompella <[email-masked]> wrote:
> 
> <snipped>

Balaji (a co-author) pointed out that BGP-LS uses 4 bytes for metrics.  A future version of the draft will update this.

Cheers,
Kireeti.

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 27 Dec 2021 20:31:05 -0500

Hi Kireeti,

The updates in version -11 look good. The proposed future updates will also
be great.
Thanks,
- Xufeng

On Sun, Dec 19, 2021 at 12:48 PM Kireeti Kompella <[email-masked]>
wrote:

> Balaji (a co-author) pointed out that BGP-LS uses 4 bytes for metrics.  A
> future version of the draft will update this.
>
> Cheers,
> Kireeti.
>
>

---

From: Tarek Saad <[email-masked]>
Date: Tue, 28 Dec 2021 17:03:25 +0000

Thanks to reviewers for the feedback, and Kireeti/authors for addressing them.
I’ve triggered an IPR poll in anticipation of the next step.

Regards,

From: Kireeti Kompella <[email-masked]>
Date: Monday, December 13, 2021 at 10:21 PM
To: Tarek Saad <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, Rakesh Gandhi <[email-masked]>, Xufeng <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, MPLS Working Chairs <[email-masked]>, mpls <[email-masked]>
Subject: Re: [mpls] MPLS-RT for draft-kompella-mpls-larp

Hi Tarek,

Thanks,
:k

On Dec 13, 2021, at 07:28, Tarek Saad <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

From: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Date: Sunday, December 5, 2021 at 12:14 PM
To: Xufeng <[email-masked]<mailto:[email-masked]>>
Cc: Tarek Saad <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, MPLS Working Chairs <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>
Subject: Re: MPLS-RT for draft-kompella-mpls-larp

Hi Tarek, Authors,

   LDP, RSVP-TE) are run.

Section 5.2

Section 7 IANA Section:

Thanks,
Rakesh

Regards,
Tarek (as MPLS WG chair)
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls