Re: [mpls] Shepherd review of draft-ietf-mpls-spring-inter-domain-oam-10

[[e-mail]]

Shraddha and Adrian,

I have snipped everything I don't talk about, but in general I agree with
Adrian's comments.

> 1. para 8
>    This mechanism uses
>    MPLS path and no changes are required in the forwarding path.
> I cannot parse this. Maybe s/MPLS path/MPLS LSPs/ ?

> <SH> I mean to say the packet is being forwarded via MPLS so IP
> connectivity is not needed.
> MPLS LSPs term will be too specific to LDP/RSVP I believe. SR RFCs don't
use the term MPLS LSPs.

I think that "This mechanism uses MPLS LSP and no changes are required in
the forwarding path." Is the best and clearest version of the text I  have
seen.

Shraddha's comment:

> <SH> I mean to say the packet is being forwarded via MPLS so IP
> connectivity is not needed.
> MPLS LSPs term will be too specific to LDP/RSVP I believe. SR RFCs don't
use the term MPLS LSPs.

Is nit entirely correct, we have had LSPs without IP connectivity almost
since day one:


The network I operated in Sweden (Utfors) started as a manually configured

network, no IP at all. Admittedly we very quickly introduced LDP, RSVP-TE
and BGP signaling to establish LSPs and VPNs.

draft-ietf-mpls-static-yang, does not rely on any signaling protocol.

RFC 8277 (replacing RFC 3107)  "Using BGP to Bind MPLS Labels to Address
Prefixes" uses LSP

The entire MPLS-TP project builds on the assumption that LSPs could be 
established by OAM tools.


I have not gone through all Spring RFC, but at least RFC 8403, uses "LSP".


So I have to conclude that the assumption is a LDP/RSVP-only concept is
not correct.


/Loa



---