RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1

Andy, 

> >My view on this is that any body who purports to be a 'standards
> >organisation' should not sanction vendor (or other, eg SP) protocol
> >codepoints.
> 
> See Q.2931 (02/95 revision is the one I'm looking at) section 
> 4.5.8 and 
> X.36 (04/95) Annex D for some examples of ITU-T usage of the 
> IEEE OUI for 
> vendor extensions and private protocol identification.
NH=> And therefore the conclusion is?.........you seem to be saying
something like 'if X commits a crime it now gives everyone the right and
also go and commit the same crime'.  I don't care which stds body does
this....it simply is not right in principle IMO.

regards, Neil

Downstream on Demand and Downstream Unsolicited - Interoperability

Hi,

   RFC 3215 (LDP State Machine) which is informational
gives precise directions on implementing the state machines
for DOD Merge,Dod Non Merge and DU.

   Is it necessary for an implementation to support
DOD Merge on one interface and DU on the other interface.

   If so, is there any informational RFC which specifies
things as clearly as RFC 3215 for interoperability.

  Thanks in Advance.

Regards,
Maheshkumar

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including

Re: Secure MPLS

What do those customers do currently for security of those links?

Ben

On Wed, Jul 31, 2002 at 02:50:04PM -0600, Black, Stephen wrote:
> To a point I agree with Ron also... but there are other considerations to
> look at... Such as government/corporate clients who need to have an ISP
> guarantee that their links are secure (i.e. a link between FBI and CIA, or a
> link from Intel in CA to Intel in NY). There are also military networks that
> might want to implement a secure form of MPLS. Granted this is a very small
> piece of the pie but it should be worth putting some effort into. As a
> client I'd rather have a combination of layers that incorporates security
> rather than a higher layer where the lower layers can be compromised without
> my knowledge. Just running IPSEC and a firewall is like putting all your
> eggs in one basket. Let the politicians worry about the escrow and seizure.
> 
> Steve
> 
> 
> -----Original Message-----
> From: Andrew G. Malis [mailto:Andy.Malis <at> vivacenetworks.com]
> Sent: Wednesday, July 31, 2002 12:39 PM
> To: Ron Bonica
> Cc: Tissa Senevirathne; mpls <at> UU.NET
> Subject: RE: Secure MPLS
> 
> 
> I agree with Ron.  From the end user point of view, some problems with 
> service provider encryption are that the tail circuits from the customer 
> premise to the service provider are unprotected (which the obvious place to 

RE: Vendor ID (OUI) encoding in LDP section 3.6.1.1

Neil,

My point was just that it's not only the IETF.  The IEEE invented OUIs and 
makes heavy use of them in their specifications (and a nice business 
selling them), and the ITU-T also uses them.

Cheers,
Andy

-------

At 8/1/2002 03:43 AM +0100, neil.2.harrison <at> bt.com wrote:
>Andy,
>
> > >My view on this is that any body who purports to be a 'standards
> > >organisation' should not sanction vendor (or other, eg SP) protocol
> > >codepoints.
> >
> > See Q.2931 (02/95 revision is the one I'm looking at) section
> > 4.5.8 and
> > X.36 (04/95) Annex D for some examples of ITU-T usage of the
> > IEEE OUI for
> > vendor extensions and private protocol identification.
>NH=> And therefore the conclusion is?.........you seem to be saying
>something like 'if X commits a crime it now gives everyone the right and
>also go and commit the same crime'.  I don't care which stds body does
>this....it simply is not right in principle IMO.
>
>regards, Neil

Fast Reroute -facility backup- rerouting control traffic after failure

This is with reference to the draft 
"draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt" for Fast
ReRoute.

To quote from the draft(described in section.6) -

  "During failure, the PLR reroutes the data packets of each 
protected LSP onto the bypass tunnel. The control messages of the 
backed-up LSPs are also sent over the bypass tunnel.  The facility 
backup uses the sender-template-specific approach to identify the 
backup tunnels."

As explained in the above paragraph,
  the control messages of the backed-up LSPs are sent over the 
bypass tunnel during failure.Does this means that after 
failure,the path refresh messages of the backed-up LSPs will sent 
through the bypass tunnel as labeled packets.If this is the case, 
then how the path messages can be forced to be sent as labeled 
packets, as RFC 2205 says that RSVP messages are sent hop-by-hop 
between RSVP routers as "raw" IP datagrams with protocol number 
46.

regards,
Priyaranjan

draft minutes from Yokohama mpls meeting

Included are the drafts minutes from the MPLS wg meeting in
Yokohama. Thanks to Dave and Eric who helped taking notes,
but have not repsonsibility for the delay in getting them
out to the list.

Please comment.

/Loa

IETF 54 MPLS WG Preliminary Notes

Thursday July 12. 9 - 11.30 AM

Chair - Loa Andersson (George Swallow not in attendance).
Note Takers - David Allan, Eric Gray

Loa:
Agenda bashing
--------------
- process reminders/blue sheets
- LDP MTU draft off the agenda
- No further comments on the agenda

Loa:
LDP (RFC 3036) to draft standard (status)
---------------------------------------------------
Loa talked about the need to collect implementation information on
LDP for taking it to Draft Standard.
It is still not clear how many other rfc's that will be affected, encap 

Re: draft minutes from Yokohama mpls meeting

Hi all,

I would like to expand a little bit on the minutes because I feel some of
the remarks may have gotten a little bit condensed.

- On the question whether or not this work was intended to be separate or
merged I replied that I felt it was useful to keep the draft as an overview
of outstanding issues but that any eventual resolution of any of the issues
could be merged with other work

- On the question about complex resource class affinity specifications I
also mentioned that the although the solution does not work in one
particular case, an operator will always know (by virtue of its resource
class specification policy) whether or not it is safe to use the proposed
solution. I also recall some support for a partial solution

- My remark on the fast reroute presentation was actually a question about
the impact of the use of backup LSPs without bandwidth reservation on the
performance of constraint-based routing algorithm (based on unreserved
bandwidth advertisements)

I hope this will provide some clarification.

Best regards,
Sven.

Loa Andersson <loa.andersson <at> utfors.se> <at> UU.NET on 02/08/2002 13:51:23

Sent by:  owner-mpls <at> UU.NET

draft-ietf-mpls-ldp-ft-04.txt

draft-ietf-mpls-ldp-ft-04.txt has been submitted and published.

The only changes are minor and editorial after WG last call.  Thanks to all who
commented on and off the list.

In summary the changes are:
- add text and definitions to clarify when a label is a full FT label, when
  it is available for checkpointing and when it is not FT at all.
- remove "changes from last edition"
- simplify IANA section and be specific about intended values
- renumber references and put them into a single section with
  two subsections.

The authors would like to ask that the draft now moves forward to the IESG.

Thanks,
Adrian

RE: Downstream on Demand and Downstream Unsolicited - Interoperability

Hi,

If any information can be provided for the following
query, it will very much appreciated.

Thanks and Regards,
MK

-----Original Message-----
From: owner-mpls <at> uu.net [mailto:owner-mpls <at> uu.net]On Behalf Of Mahesh
kumar S
Sent: Thursday, August 01, 2002 11:18 AM
To: mpls <at> uu.net
Subject: Downstream on Demand and Downstream Unsolicited -
Interoperability

Hi,

   RFC 3215 (LDP State Machine) which is informational
gives precise directions on implementing the state machines
for DOD Merge,Dod Non Merge and DU.

   Is it necessary for an implementation to support
DOD Merge on one interface and DU on the other interface.

   If so, is there any informational RFC which specifies
things as clearly as RFC 3215 for interoperability.

  Thanks in Advance.

MIB Question