Re: [mpls] MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-02

[Shraddha Hegde <[e-mail]>]

Thanks for the review and comments Adrian. 
I'll add a new section as per your suggestion.

Rgds
Shraddha


Juniper Business Use Only

-----Original Message-----
From: Adrian Farrel <[e-mail]> 
Sent: Friday, June 4, 2021 7:21 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [mpls] MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-02

[External Email. Be cautious of content]


Hi All,

I'm late to this party. Sorry. Responding on the top of thread to make it easier to find.

I understand why you use the term "domain" and it would be perfectly reasonable except that RFC 8402 takes that term and gives it very specific meaning, admittedly as "SR domain" most of the time, but degrading to just "domain" on page 7. 8402 does also have one mention of "IGP domain" and one of "routing domain". Section 4.2 got away with "source-routed inter-domain paths" while Section 8 says that SR operates "within a trusted domain" with traffic filtering at domain boundaries (section 8.1 has a lot of information that should be relevant to this document).

Recently, there has been a lot of confusion (in the IESG, for example) as to what the scope and limits of an "SR domain" are. I think that a lot of this comes from Section 8 of RFC 8402. At the very least, there was a misunderstanding of the intended scope of SR since (except in a few multi-AS
companies) adjacent ASes to not have a shared trust model.

I suggest that you take some time (probably in Section 1) with a new subsection on "Definitions of Domain" to try to clarify this.

One thing we noticed in pushing draft-ietf-bess-datacenter-gateway through the IESG was that it is possible to build on the "SR domain" concept in a constructive way such that it is constructed of:
- all nodes in the source SR-enabled network
- all nodes in the destination SR-enabled network
- all ASBRs along the path from source to destination network

While it may (or may not) be the case that the transit nodes in an AS are SR-enabled, it is not important to the way you are building an "SR overlay".

Cheers,
Adrian

-----Original Message-----
From: mpls <[e-mail]> On Behalf Of Mach Chen
Sent: 04 June 2021 02:55
To: Shraddha Hegde <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls] MPLS-RT review on
draft-ninan-mpls-spring-inter-domain-oam-02

Hi Shraddha,

Thanks for considering the comments, looking forward to the revision.

Best regards,
Mach

> -----Original Message-----
> From: Shraddha Hegde [mailto:[e-mail]]
> Sent: Thursday, June 3, 2021 12:30 PM
> To: Mach Chen <[e-mail]>;
> [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: MPLS-RT review on 
> draft-ninan-mpls-spring-inter-domain-oam-02
>
> Hi Mach,
>
> Thanks for the review.
> Pls see inline ...
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Mach Chen <[e-mail]>
> Sent: Wednesday, June 2, 2021 9:29 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-02
>
> [External Email. Be cautious of content]
>
>
> Hi,
>
> I am selected as a MPLS-RT reviewer of 
> draft-ninan-mpls-spring-inter-domain-oam.
>
> After review, I think the problem that the draft is trying to address 
> is
valid and
> useful. The solution is overall workable. My comments are mainly about
Type 3
> and Type 4 segment sub-TLV, I think it's better to address these 
> comments before the adoption.
> <Shraddha> Sure.
>
> Type 3 and 4 sub-TLVs are supposed to be used when the headend/PMS 
> does not have the labels or SRGB information of the remote nodes, 
> <Shraddha>
yes
> because  these remote nodes lie in a different domain and SRGB 
> information may not be available at the headend in some cases.
>
>  and assume that the receiving node (egress node) can derive the MPLS
labels
> according to the IPv4/IPv6 addresses.
> <Shraddha>
> I will add a section with  example of multi-domain network with 
> different
SRGB
> and explain how Type 3 and Type 4 Segments can be used while building 
> the return path dynamically for traceroute. The key is only the top 
> segment
has to be
> Type 3/Type 4 the remaining segments to be of type label. For the Top
segment,
> label has to be derived from the SRGB of the receiving node (not 
> someone
else's)
> so its expected to be available.
>
>
> This assumption may not hold, because given that the headend/PMS does 
> not have the information, it is very likely that the receiving node 
> has no the information either. So the draft should add more text to 
> clarify the use
cases of
> type 3, 4 sub-TLVs, or just remove them.
> <shraddha> I'll add more text to describe clearly how type3/Type 4 
> should
be
> used.
>
> In addition, given type 3 and 4 have valid use case, the optional SID
fields of type
> 3 and 4 are redundant, I think that they should be removed.
> <shraddha> SIDs are optional anyway. I would prefer to keep it in 
> order to
be
> consistent with segment routing
> path description.
>
> Section 4,
> "Below types of segment sub-TLVs are applicable for the Reverse Path
>    Segment List TLV."
>
> Should the "Reverse Path Segment List TLV" be "Return Path TLV"?
> <shraddha> Good catch. I'll fix it.
>
> Best regards,
> Mach

_______________________________________________
mpls mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!T-XDUtVJDs_dsTmVf1bWX7WGfgK9jxzT9ofqUK7yXUg9uVOmmlcazjp1aHKwlJZ8$