The MPLS WG Archive

[Scott Bradner <sob@harvard.edu>]

after reviewing the discussion on the draft response to SG 13 about
draft-ohta-mpls-label-value-01.txt - I simplified the letter and just sent
the following to  Brian Moore (SG 13 chair)

Scott

------------------
SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director 

TITLE: Response to "Communication on the status of the request on the assignment of
a reserved label value for MPLS OAM packet identification"
    
The MPLS working group discussed SG 13's request for the assignment of a reserved
label value for MPLS OAM packet identification (draft-ohta-mpls-label-value-01.txt)
during the MPLS session during the recent IETF meeting in Minneapolis.  There was
some disagreement during the discussion about the long term implications  of the
IETF granting this request.
     
During the discussion it was noted that there are a number of references to what
might be modifications to IETF protocols in Y.1711.  For example, Section 6.1
states, "Ideally this should be done automatically  via LSP signaling at LSP set-up
time (e.g. via a CR-LDP or RSVP  control-plane mechanism), but it could also be
configured manually."

In order to understand the possible consequences of allocating an MPLS codepoint in
response to the request in draft-ohta-mpls-label-value-01.txt the MPLS working group
would like to understand the what modifications that SG13 may be assuming will be
needed to other IETF protocols.  (LDP, CR-LDP, RSVP, PIM and BGP have been suggested
as IETF protocols that might be impacted.)

A further concern is the potential impact on the MPLS forwarding plane as currently
defined.  In certain points in a MPLS network, based on an incoming label, the label
is removed and the packet is forwarded with no further inspection of subsequent
headers (be it another MPLS label or some other header). Y.1711 seems to imply that
the above behavior would not satisfy Y.1711. Specifically, there are some cases
where Y.1711 would expect a network element to intercept an OAM packet.   Thus, the
MPLS working group would like to understand if SG 13 thinks that Y.1711 assumes
functionally that might raise issues of backward compatibility with existing MPLS
systems and ASICs.