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

[Shraddha Hegde <[e-mail]>]

Hi Italo,

An updated version -06 is posted addressing comments.
Pls take a look.

Rgds
Shraddha


From: Shraddha Hegde
Sent: Friday, March 6, 2020 4:12 PM
To: Italo Busi <[e-mail]>; [e-mail]; [e-mail]; Mach Chen <[e-mail]>
Cc: [e-mail]; Bocci, Matthew (Nokia - GB) <[e-mail]>; Alexander Vainshtein <[e-mail]>; Sam Aldrin <[e-mail]>
Subject: RE: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Hi Italo,

Thanks for review and comments. Pls see inline…

From: Italo Busi <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, February 26, 2020 10:30 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Mach Chen <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Bocci, Matthew (Nokia - GB) <[e-mail]<mailto:[e-mail]>>; Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; Sam Aldrin <[e-mail]<mailto:[e-mail]>>
Subject: RE: MPLS-RT review of draft-hegde-mpls-spring-epe-oam

Hi all,

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

I have reviewed the latest version of the draft which has been published two days ago (draft-hegde-mpls-spring-epe-oam-05).

I think that the document is coherent, is it useful (i.e., it addresses a real need for operational networks), and it is technically sound.

Therefore, I think that the draft is ready to be adopted as a WG document.

I have few comments that can be addressed either before or after WG adoption.

1.       The Introduction mentions the procedures defined in section 7 of RFC8287 and clarified by RFC8690.

My understanding is that RFC8690 clarifies how to use the length field with the sub-TLVs defined in section 5 of RFC8287 and therefore it is not strictly applicable to this draft.
<shraddha> yes. You are right. I updated this sentence and referred 8690 based on comment that 8287
Has an important clarification in RFC 8690 so it should be reference.

However, it would be worthwhile clarifying in section 4 of this draft how the length field should be set for the EPE SID sub-TLVs. An example would also be useful.
<shraddha> yes updated the draft.

2.       I guess that all the information elements used in the sub-TLVs defined in section 4 of this draft are those defined in draft-ietf-idr-bgpls-segment-routing-epe.
<Shraddha> Yes.

It would be worthwhile to reference draft-ietf-idr-bgpls-segment-routing-epe for these definitions.
<Shraddha> yes, normative reference added.

I guess this would also help resolving comment #1 from Sasha on link-local IPv6 addresses and unnumbered interfaces: whatever is supported by draft-ietf-idr-bgpls-segment-routing-epe should be also supported by this draft (and vice versa)
<shraddha> updated with link-local addresses FFS.

3.       In Figure 2, the “No.of IPv6 interface pairs” field seems a bit redundant since the information can be inferred from the “Length” and “No.of IPv4 interface pairs ” fields
<shraddha> Since IPv4 and ipv6 address pair may be present simultaneously, we need this field.

This is ok for me but please add some text to clarify whether the receiver should/shall perform some validation check
 <shraddha> sure will add new section in next revision.
4.       Figure 3 is not fully clear

If I understand well, the “Remote As Number”, “Remote BGP Router ID”, “No.of IPv4 interface pairs”, … fields are repeated for each element in the set.
<Shraddha> yes, these elements are repeated for each set.

It may be worthwhile to split the figure into two: one describing the TLV containing one or more “elements” and one describing the fields used in each element.
<Shraddha> Yes. updated

5.       In Figure 6, the “No.of elements in set” field as well as the “No.of IPv6 interface pairs” field of the last element in the set seem a bit redundant since the information can be inferred from the “Length” and “No.of IPv4 interface pairs ” of the last element in the set fields
<Shraddha>Since both IPv4 and IPv6 addresses pairs may be present simultaneously, number of pairs field is required.

As for comment #3 above, this is ok for me but please add some text to clarify whether the receiver should/shall perform some validation check
 <shraddha> sure will add new section in next revision.
Italo

> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: venerdì 14 febbraio 2020 05:53
> To: Bocci, Matthew (Nokia - GB) <[e-mail]<mailto:[e-mail]>>; Alexander
> Vainshtein <[e-mail]<mailto:[e-mail]>>; Sam Aldrin
> <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]