The MPLS WG Archive

["David Allan"<dallan@nortelnetworks.com>]

Title: RE: response to ITU-T SG13

Hi Scott:

I think readability would be enhanced if the third paragraph was deleted..."Since manual configuration .... before Y.1711 would be seen as a complete solution."....The third para discusses if changes to CR-LDP and RSVP are expected and a few paragraphs later the question is enlarged to include LDP, PIM and BGP.

I'll plead ignorance, but I'm not sure why PIM is on the list...?

cheers
Dave

> -----Original Message-----
> From: Scott Bradner [mailto:sob@harvard.edu]
> Sent: Friday, April 12, 2002 4:45 PM
> To: mpls@UU.NET
> Subject: response to ITU-T SG13
>
>
>
> This is the response to
> http://www.ietf.org/IESG/LIAISON/ITU-SG13-MPLS-OAM.txt
> that was discussed during the MPLS session in Minneapolis
> that I plan to
> send early next week unless the WG has a problem with that.
> (Thanks to George for the draft that this is based on)
>
> 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
> modifications to IETF protocols in Y.1711.  In particular, 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.   The mechanism for
> achieving this
> configuration is outside the scope of this Recommendation."
>
> Since manual configuration is probably not an option for
> anything beyond a
> very limited deployment the implication is that the ITU will
> require the
> IETF to change CR-LDP and RSVP before Y.1711 would be seen as
> a complete
> solution.
>
> Also in section 6.3, Forward Defect Indication, the following
> text may be
> read as indicating an assumption of future changes in  IETF protocols
> dealing with LSP signaling.
>
> "It is important that the LSP sink point knows (for the
> duration that the
> LSP is in service) any server->client LSP label mappings that were in
> existence prior to the defect.  Although the exact means for
> achieving this
> are outside the scope of this Recommendation, some examples
> of how these
> server-> client layer label mappings could be configured are
> as follows:
>    o manually, via the NMS say; 
>    o automatically on LSP set-up via extensions to LSP signaling ..."
>
> 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 full
> scope and extent
> of the modifications that SG13 may be assuming to other IETF
> protocols,
> including LDP, CR-LDP, RSVP, PIM and BGP.
>
> A further concern is the 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. This raises issues of backward
> compatibility with existing MPLS systems and ASICs. 
>
> The MPLS working group would like to understand if Y.1711 assumes
> functionally that could not be supported by simply changing
> software in
> existing MPLS implementations.
>
> 
>