Subject: RE: response to ITU-T SG13

From: Shahram Davari <[email-masked]>
Date: Mon, 15 Apr 2002 07:43:06 -0700

Hi Scott,

Here are my comments/questions:

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

Why are optional extensions to CR-LDP and RSVP-TE a concern for IETF?
After all these protocols are constantly being extended (e.g. GMPLS, DS-TE, etc.)

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

Why PIM?

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

I assume this is talking about PHP. 

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

>From which part of the Y.1711 did you get this impression? No where in
Y.1711 is any requirement for intercepting OAM packets, not even at the
PHP point. The OAM packet is only visible at the ingress and egress LSRs.

I suggest removing this paragraph, becasue it shows a lack of understanding
of Y.1711.
  
> 
> 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.

Some vendors may have implemented their MPLS data-plane in hardware and some in software. Why should a vendor's implementation be a concern for a standard body such as IETF? 

I therefore suggest removing this paragraph. 

Yours,
-Shahram

---

From: Eric Rosen <[email-masked]>
Date: Mon, 15 Apr 2002 14:19:37 -0400

Shahram> Some vendors may have implemented their MPLS data-plane in hardware
Shahram> and some  in software.  Why should a  vendor's implementation  be a
Shahram> concern for a standard body such as IETF?

Shahram> I don't  think specific implementations  should be a concern  for a
Shahram> standard  body such  as  IETF.  You could  always  find a  specific
Shahram> implementations that  can't support  a new function.  Any objection
Shahram> regarding backward compatibility should be based on a standard.

Are  you  saying  that  the  characteristics  of  existing  deployments  and
implementations should  deliberately be  ignored by the  WG as it  makes its
decisions?

I'd have  to disagree.  If  one is trying  to produce solutions  which solve
real problems for real people, and which will be adopted by the real market,
then one is well-advised to take the existing situation into consideration.  

I am not aware of any IETF  policy or precedent that says to ignore existing
implementations or deployments.