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

From: Mach Chen <[email-masked]>
Date: Wed, 2 Jun 2021 03:59:14 +0000

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.

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, and assume that the receiving node (egress node) can derive the MPLS labels according to the IPv4/IPv6 addresses. 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.

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. 

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"?

Best regards,
Mach

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 3 Jun 2021 04:30:14 +0000

Hi Mach,

Thanks for the review.
Pls see inline ...

Juniper Business Use Only

-----Original Message-----
From: Mach Chen <[email-masked]> 
Sent: Wednesday, June 2, 2021 9:29 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-02

[External Email. Be cautious of content]

Hi,

<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,

Should the "Reverse Path Segment List TLV" be "Return Path TLV"?
<shraddha> Good catch. I'll fix it.

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Fri, 4 Jun 2021 01:55:06 +0000

Hi Shraddha,

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

Best regards,
Mach

> From: Shraddha Hegde [mailto:[email-masked]]
> Sent: Thursday, June 3, 2021 12:30 PM
> To: Mach Chen <[email-masked]>;
> [email-masked]
> Subject: RE: MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-02
> 
> Hi Mach,
> 
> Thanks for the review.
> Pls see inline ...
> 
> 
> 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.
> 
> 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.
> 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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 4 Jun 2021 14:50:45 +0100

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 <[email-masked]> On Behalf Of Mach Chen
Sent: 04 June 2021 02:55
To: Shraddha Hegde <[email-masked]>;
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review on
draft-ninan-mpls-spring-inter-domain-oam-02

Hi Shraddha,

Best regards,
Mach

>  and assume that the receiving node (egress node) can derive the MPLS
labels
> according to the IPv4/IPv6 addresses.
> <Shraddha>
> <shraddha> I'll add more text to describe clearly how type3/Type 4 should
be
> used.
> <shraddha> SIDs are optional anyway. I would prefer to keep it in order to
be
> consistent with segment routing
> path description.
> 
> Section 4,

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

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 9 Jun 2021 12:09:46 +0000

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

Rgds
Shraddha

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

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 <[email-masked]> On Behalf Of Mach Chen
Sent: 04 June 2021 02:55
To: Shraddha Hegde <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review on

Hi Shraddha,

Best regards,
Mach

> Subject: RE: MPLS-RT review on 
> After review, I think the problem that the draft is trying to address 
> is
valid and
> 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.
>
labels
> 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
> label has to be derived from the SRGB of the receiving node (not 
> someone
else's)
> 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
be
be

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