Re: [mpls] MPLS-RT review of draft-hegde-mpls-spring-epe-oam

[Alexander Vainshtein <[e-mail]>]

Adding the MPLS WG list.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Alexander Vainshtein <[e-mail]>
Sent: Tuesday, February 18, 2020, 14:04
To: [e-mail]; Mach Chen
Cc: [e-mail]
Subject: RE: MPLS-RT review of draft-hegde-mpls-spring-epe-oam


Hello,

I have been selected as one of the  MPLS-RT reviewers of draft-hegde-mpls-spring-epe-oam.



This review presumably is part of the process of adoption of this draft as an MPLS WG document, and should answer the following questions:

1.       Does this draft address a real problem?

2.       Is the current version a reasonably good start for solving this problem?

3.       Are there any issues that must be fixed prior to adoption of the draft as a WG document?



After reading the draft I think that the answers to questions (1) and (2) above are positive.



I have a couple of technical issues with the draft listed below.



1.       All sub-TLVs defined in the draft include lists of pair of local and remote IPv4 or IPv6 addresses describing links between the advertising node and the eBGP neighbor for which the EPE SID is advertised.

a.       I wonder if link-local IPv6 addresses are acceptable in these lists

b.       I also wonder how unnumbered P2P IPv4 interfaces could be specified in these lists.

2.       All sub-TLVs defined in the draft include, as one of their files the field “Local AS” that is always defined as ”4 octet unsigned integer representing the Member ASN inside the Confederation”. I wonder if this definition equally applies to the case when the so-called “Local AS” mechanism defined in RFC 7705<https://tools.ietf.org/html/rfc7705> is used vs. a specific eBGP peer. In these scenarios the number of the AS to which the node that advertises an EPE SID differs from the AS number that this node uses in its OPEN message to the specific neighbor.

3.       The document states in Section 1 that “Other procedures for mpls ping and traceroute as defined in [RFC8287<https://tools.ietf.org/html/rfc8287>] are applicable for EPE-SIDs as well”.

a.       Such a blank statement requires some clarification IMHO

b.       Specifically, RFC 8287 states in Section that the Traceroute initiator, upon receiving an MPLS Echo Reply message that includes the FEC Stack Change TLV with one or more of the original segments being popped “MAY remove a corresponding FEC(s) from the Target FEC          Stack TLV in the next (TTL+1) traceroute request”. I wonder if, in the case of EPE SIDs, MAY requirement should not be upgraded to SHOULD or even MUST for security reasons



Neither of the issues mentioned above looks to be as blocking WG adoption of the draft. They can safely be resolved after adoption.



Hopefully this review will be useful.



Regards,

Sasha



Office: [phone]

Cell:      [phone]

Email:   [e-mail]



-----Original Message-----
From: Loa Andersson <[e-mail]>
Sent: Friday, February 14, 2020 6:53 AM
To: Bocci, Matthew (Nokia - GB) <[e-mail]>; Alexander Vainshtein <[e-mail]>; Sam Aldrin <[e-mail]>; Italo Busi <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: MPLS-RT review of draft-hegde-mpls-spring-epe-oam



Mathew, Sam, Sasha and Italo,



You have be selected as MPLS-RT reviewers for draft-hegde-mpls-spring-epe-oam.



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

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



Are you able to review this draft by Feb 28, 2020? Please respond in a timely fashion.





Thanks, Loa

(as MPLS WG chair)

--

--





Loa Andersson                        email: [e-mail]<mailto:[e-mail]>

Senior MPLS Expert

Bronze Dragon Consulting             phone: [phone]


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________