Subject: RE: response to ITU-T SG13

From: "David Allan"<[email-masked]>
Date: Mon, 15 Apr 2002 09:34:54 -0400

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:[email-masked]]
> Sent: Friday, April 12, 2002 4:45 PM
> To: [email-masked]
> 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.
> 
>  
>

---

From: Loa Andersson <[email-masked]>
Date: Mon, 15 Apr 2002 16:35:00 +0200

All,

did read this before it was sent. I thought that PIM came in via the
mpls multicast framework, just now processed by the IESG to the
rfc-editor. See e.g. page 18 in the framework:

"a) Multicast routing messages: protocols as PIM-SM and CBT have
    explicit Join messages which could carry the label mappings.  This
    approach is described in [FARI].  When different multicast routing
    protocols are deployed, an extension to each of these protocols has
    to be defined."

But I might be wrong. The [FARI] did not go anywhere did it?

/loa

David Allan wrote:

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

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se