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 <mpls-bounces@ietf.org> On Behalf Of Mach Chen
Sent: 04 June 2021 02:55
To: Shraddha Hegde <shraddha@juniper.net>;
draft-ninan-mpls-spring-inter-domain-oam@ietf.org
Cc: mpls@ietf.org; mpls-chairs@ietf.org
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:shraddha@juniper.net]
> Sent: Thursday, June 3, 2021 12:30 PM
> To: Mach Chen <mach.chen@huawei.com>;
> draft-ninan-mpls-spring-inter-domain-oam@ietf.org
> Cc: mpls-chairs@ietf.org; mpls@ietf.org
> 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 <mach.chen@huawei.com>
> Sent: Wednesday, June 2, 2021 9:29 AM
> To: draft-ninan-mpls-spring-inter-domain-oam@ietf.org
> Cc: mpls-chairs@ietf.org; mpls@ietf.org
> 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
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls